On 09/30/2015 07:54 PM, Bob Copeland wrote:
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).
I agree.
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.
I'm working with firmware guy and there is possibility that firmware
handles this issue properly.
Thanks,
Peter
--
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
