On Sat, Apr 25, 2015 at 01:54:20AM +0800, Chun-Yeow Yeoh wrote:
> But we have the following in mesh forwarding:
>
> static ieee80211_rx_result
> ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
> {
> ...
> if (!ieee80211_is_data(hdr->frame_control) ||
> !(status->rx_flags & IEEE80211_RX_RA_MATCH))
> return RX_CONTINUE;
>
> ...
> mesh forwarding
> }
>
> So this means that even if the device in promiscuous mode (RX_RA_MATCH
> clear), the frame won't be forwarded, right?
Yes, agreed. I still don't understand how it could happen with
intermediate nodes.
> Thomas did mention whether this is retransmit frame not ACKed by RA. I
> expect the following happen:
>
> Node A ---> Node B ----> Node C or D ---> Node E
>
> A transmits to B. B receives but no ACK received by A. B forwards to C.
>
> For the same frame, A re-transmits again. (Path refresh) B now
> forwards to D instead of C. So E will receive duplicate frames from
> both C and D in mesh network.
Hmm, but B should already filter this duplicate on the basis of having
same 802.11 sequence number as one already received, in
ieee80211_rx_h_check_dup(), right?
Just to summarize the state of affairs as I understand it now for when
someone revisits this thread in 2 more years' time :)
1. On some devices the lower-level drivers do not filter on RA (addr1) by
default in mesh mode.
2. On other devices, when a monitor vif is added, same thing happens as
in 1.
Either 1 or 2 is sufficient to hear frames with a different RA but same
DA.
3. A device in a bridge will have IFF_PROMISC set, which prevents frames
not matching RA from being discarded.
4. Due to missing check in deliver_skb(), all of these frames are passed
up the stack.
I could reproduce Francois' problem on my hardware with 3 stations all
in range, and fixing mesh paths A <-> B <-> C, putting C in a bridge and
adding a monitor interface on C, then pinging from A to C.
5. Johannes Berg posted patches to remove IFF_PROMISC special cases, so going
forward, we shouldn't hit this.
6. I still don't understand how intermediate nodes might experience this
problem due to the check in the forwarding path and existing sequence number
checks. I guess we could try to make it happen with a bunch of
simulated nodes and mac80211_hwsim/wmediumd.
--
Bob Copeland %% http://bobcopeland.com/
_______________________________________________
Devel mailing list
[email protected]
http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
