[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