Sorry I miss out your previous email. > We did this over a year ago and I don't think we saw routing loops though > iirc we saw better performance when we made the change. Most likely because > of the other problem with the original code: it creates a path to the ta if > none exists but does not go through discovery to do so. Yes, it is a direct hop towards the mgmt->sa, > So if the direct hop > is not the best path you're going to be stuck with a crappy path until the > next refresh. But hey, the code has already compared the path metric, right? Next refresh, so if you reduce the active path timeout (dot11MeshHWMPactivePathTimeout), you solve the problem, right? > In any case updating metrics without doing an SN feasibility check is highly > suspect. As cited in section 13.10.8.4, "the mesh STA may create or update its forwarding information to the transmitter of the element if the path metric improves." So it is correctly implemented. > I'm not 100% sure this instance will cause routing loops but I do > know that every time I have tried to be clever and optimize routing without > looking at both the SN and metric I have wound up with routing loops. I would recommend to add nl80211 command to disable this. After all, it may change other people's network behavior. Also, you may post you patch to o11s mailing list and your test scenario. Maybe others can verify as well to be 100% sure. Thanks --- Chun-Yeow -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
