On Mon, Sep 28, 2015 at 10:27:30AM -0700, Peter Oh wrote: > I prefer the current design to this new approach because drivers already > know if it's mesh capable or not at build time, hence adding runtime > configuration is redundant. I do think the proposed patch is a bit overboard, so I suppose my vote is to keep it the way it is, even if a little user-unfriendly. > One more thing we have to think about is enabling mesh in only raw mode. > In standard view point, mesh is only available in raw mode on ath10k, > however ath10k is also able to run mesh in native WiFi mode in current > mac80211 design since mac80211 handles packets per interface. So that > mac80211 knows that packets are for mesh without looking at mesh control > present bit when they come into mesh interface. This is true, it'll work with mac80211, but it violates the standard (802.11-2012 8.2.4.7.3). For the benefit of others, as I just retested non-rawmode -- the issue is that QoS control in nwifi frames is missing the "Mesh Control Present" bit. However, it still includes the mesh control field, which is the part that has the mesh sequence number and address extension fields. As a result, a packet parser might misinterpret the mesh control field as the LLC header -- the wireshark dissector at least gets confused like this. I would think a small change to ath10k firmware could fix this though, vendor willing. -- Bob Copeland %% http://bobcopeland.com/ -- 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
