On Thu, Mar 7, 2013 at 8:16 AM, Yeoh Chun-Yeow <[email protected]> wrote: >> It is possible that this will happen if the path selection algorithm >> determines a multi-hop path is in fact "better". This bit of code in >> net/mac80211/rx.c: >> >> /* Frame has reached destination. Don't forward */ >> if (!is_multicast_ether_addr(hdr->addr1) && >> ether_addr_equal(sdata->vif.addr, hdr->addr3)) >> return RX_CONTINUE; >> >> will accept frames as long as the DA matches the local address. Then >> the receiving node will get both the original and forwarded frame (if >> it is in range, of course). Maybe this is an argument for only >> matching against TA? Except IEEE 802.11-2012 9.32.4.2(b) actually >> states that this is the right address to check. > > As mentioned in 9.32.7 in IEEE 802.11-2012, probably we can use the > mesh sequence number to detect the duplicate packets and silently > dropping them from forwarding or passing to the upper layer. It is > similar to the mesh_rmc_check routine for multicast frame.
Oh nice, that would work. Of course this doesn't prevent redundant transmissions, but at least the receiver will be less confused. >> So I'm not sure what the right approach in this case is. Live with >> duplicate MSDUs? Fix the path selection so if an established peer >> matches the destination, that hop is "best"? > > Another alternative is to increase the mesh_hwmp_active_path_timeout > so that the active path is not refresh so frequently (default is 5s). The timeout does seem a little aggressive at the moment. -- Thomas _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
