Packets not received on node when mesh TTL equals 1

[jlopex]

If mesh ttl is set to 1 broadcast / multicast are droped and not handled by receiver.

Facts:

When mesh_ttl is set to 1, ARP frames (Broadcast) are not being responded (sniffer shows them on the air).
When mesh_ttl is set to 1, Multicast frames are not received on node (sniffer also shows them on the air).

Both cases work correctly when ttl = 2, in that case host receives data and forwarded over the air.

[jcard0na]

I believe this was broken in commit:

commit 30789eb
Author: Thomas Pedersen thomas@cozybit.com
Date: Thu Nov 24 17:15:26 2011 -0800

mac80211: clean up rx_h_mesh_fwding

Lose about two levels of unnecessary indentation.

Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The previous behavior of net/mac80211/rx.c:ieee80211_rx_h_mesh_fwding() for multicast traffic was to:

1. check if (unicast) frame had reached its destination
2. decrement ttl
3. clone and forward if ttl > 0
4. receive locally if ttl == 0

        if (is_multicast_ether_addr(hdr->addr1) ||
            sdata->dev->flags & IFF_PROMISC)
                return RX_CONTINUE;

After the above referenced commit, the receiving station just drops all the received (multicast) ttl==1 frames:

+       if (!--mesh_hdr->ttl) {
+               IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, dropped_frames_ttl);
+               return RX_DROP_MONITOR;
+       }

The fix would probably be to just return RX_CONTINUE.

[jcard0na]

Fixed: https://patchwork.kernel.org/patch/1640321/