[FS#714] ARP/Broadcast does not reach other clients in the same WLAN

OpenWrt Bugs openwrt-bugs at lists.openwrt.org
Sun Dec 27 03:29:40 EST 2020


THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#714 - ARP/Broadcast does not reach other clients in the same WLAN
User who did this - Catalin Patulea (cpatulea)

----------
+1 seeing this on OpenWrt 19.07.2 on a Buffalo WZR-600DHP.

With default settings ("Isolate clients" *unchecked*), clients cannot 'ping' each other and Chromecast (which relies on multicast) is very unreliable. The interface and hostapd parameters are:

# grep isolate /var/run/hostapd-phy0.conf
ap_isolate=1
# ( cd /sys/devices/virtual/net/br-lan/lower_wlan0/brport; g
rep -H . multicast_to_unicast hairpin_mode; )
multicast_to_unicast:1
hairpin_mode:1

For a simple ping test, using a third device as 802.11 sniffer, we can see ARP broadcast sent by client1 (.10):
3937  0.022 IntelCor_e5:dd:5a   Broadcast     ARP 130 Who has 192.168.1.36? Tell 192.168.1.10

these are lost, there is no reply (.36), I think due to 802.11 powersave (?). Client 2 is probably in powersave, as most 802.11 clients usually are, and only AP knows the right moment to transmit frames (just after beacon frame, or PS-Poll). Client 1 always gets unlucky and sends when C2 is sleeping.


When setting the following settings:
config interface 'lan'
        option multicast_to_unicast '0'
config wifi-iface 'default_radio0'
        option isolate '0'

then the interface and hostapd parameters are:
~# grep isolate /var/run/hostapd-phy0.conf

# ( cd /sys/devices/virtual/net/br-lan/lower_wlan0/brport; g
rep -H . multicast_to_unicast hairpin_mode; )
multicast_to_unicast:0
hairpin_mode:0

now the clients can reach each other, by AP re-transmit the frames (from looking at 802.11 "Transmitter address" and "Receiver address" fields):

[c1->ap] 14378	2.156	192.168.1.10		192.168.1.36		62	ICMP	186	Echo (ping) request  id=0x0ca6, seq=1/256, ttl=62 (no response found!)
[ap->c2] 14380	0.000	192.168.1.10		192.168.1.36		62	ICMP	186	Echo (ping) request  id=0x0ca6, seq=1/256, ttl=62 (reply in 14382)
[c2->ap] 14382	0.001	192.168.1.36		192.168.1.10		64	ICMP	186	Echo (ping) reply    id=0x0ca6, seq=1/256, ttl=64 (request in 14380)
[ap->c1] 14384	0.000	192.168.1.36		192.168.1.10		64	ICMP	186	Echo (ping) reply    id=0x0ca6, seq=1/256, ttl=64

I think AP re-transmit is necessary for reliable transmission, since only AP is aware of client powersave state, can buffer frames, etc.

The fact that re-transmit does not work with default settings ("Isolate clients" disabled) seems like a significant bug to me, wish the bug "Priority" would be increased.
----------

More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=714#comment9216

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.



More information about the openwrt-bugs mailing list