Wifi interface replies on arp requests only in promiscuous mode

[ingo-h]

trafficstars

On working with proxy arp I have found this issue with a RPi 3B and 3B+. It should work without promiscuous mode like any other computer. I verified it with my laptop that does not need promiscuous mode.

The problem can be reproduced with this setup:
rpi-parp - RasPi with proxy arp enabled
host-eth - host 192.168.10.60 on the ethernet port of the RasPi
host-wifi - host in the wlan associated to the wifi interface of the RasPi

Setup proxy arp on rpi-parp:

rpi-parp ~# echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
rpi-parp ~# echo 1 > /proc/sys/net/ipv4/ip_forward
rpi-parp ~# ip route add 192.168.10.60/32 dev eth0

If you ping from host-wifi ping 192.168.10.60 you will only get timeouts. tcpdump shows you that you do not get arp replies from rpi-parp. Of course tcpdump on host-wifi. If you sniff on rpi-parp it suddenly works because tcpdump sets the interfaces to promisc mode. Verify it with:

rpi-parp ~# ip link set wlan0 promisc on

and ping again from host-wifi. You will get then ping replies.

How can I make this working without promiscuous mode?

[pulpo]

Same problem here, discovered when tried to use metallb with k3s (https://k3s.io/) over raspbian.

[jrcichra]

sudo ifconfig wlan0 promisc

Worked for me. Does this persist for reboots or is there a config I can change?

[jrcichra]

I'm going to do a terrible thing and put it in /etc/rc.local for now.

[JamesH65]

rc.local is probably the best approach.

Closing this issue as questions answered/issue resolved.

[DTMW2]

Hi,

same problem here, but stranger: Pi3B+ newest Software, hostapd on wifi interface + dnsmasq -> clients receive a DHCP lease but only after activating promisc on the wifi interface the Pi responds to PING and all other unicast traffic.

I think this is a bug. Why did you close this issue?

Kind regards!

[mortenlj]

I also have this problem, and putting the interface in promiscuous mode seems to make something break, so the pi drops of the network and has to be rebooted. As a work around, it doesn't work for me. Any chance this can be reopened?

[jrcichra]

I apologize, I see my answer used promiscuous mode, but the author of this issue did not want a promiscuous solution. I second the reopen.

[vrodic]

I have the same issue (Raspberry Pi Zero W not responding to ARP requests, therefore not being visible/connectable through ssh on my network after some time).

This is a related thread that provides an alternative workaround: https://www.raspberrypi.org/forums/viewtopic.php?t=32398

[scyto]

I am not sure this is an arp issue - it wouldn't reply to an ARP if it doesn't have an IP....

I realized after much hair pulling today my pi zero and pi4 disappeared when the 34 minute DHCP lease ran out (they were still associating with the APs). I also have DHCP dump running.

I have increase the lease time to 1 day to see if that resolves the issue or not....

--edit-- yes my symptoms were directly related to DHCP expiration period (lease time was 31 minutes). i don't have time to troubleshoot further so just manually configured the IP on the PI to avoid the issue entirely. I hope this might help someone else.

[arslanakhtar61]

I have already tried to add the following but still it doesn't survive the reboot.

#/etc/rc.local
ifconfig wlan0 up
ifconfig wlan0 promisc

I have asked the same question here I am using raspberry pi 4 with ubuntu 64bit 20.10, k3s cluster, metallb in layer2 mode (with wlan0 wifi connecting to router only), and traefik-ingress-controller.

[fearek]

we have almost 2022 and this is still not fixed... workaround is sudo watch -n 3600 sudo arping -c 1 -I interface -A rpiaddress replacing -n with seconds interval interface with your network interface ex wlan0 -A with the ip address for rpi (keep it static I guess)

[ingo-h]

Hi @JamesH65, you wrote

Closing this issue as questions answered/issue resolved.

The last sentence of my opening issue is:

How can I make this working without promiscuous mode?

I cannot find the answer as you stated. May it be possible that you reopen the issue?

[fearek]

We are in 2022 and this is STILL not fixed

[JamesH65]

Happy to reopen, but I doubt it will get a huge amount of attention in the near future, other more important issues in the queue.

[JamesH65]

@pelwell Can this go on any list of wireless issues that get passed up to whoever currently makes the chip?

[ericofusco]

Same issue here. I have a Raspberry Pi Model 4B and enabling promiscuous mode did the trick. I have a k8s cluster setup with metallb using ARP, related issue: https://github.com/metallb/metallb/issues/253

[jtkDvlp]

Same issue here rpi zero w, very annoying.

@fearek I got the log "Timeout". How does your workaround work? If the RPI sends an ARP-Reply with its IP, who will notice an cache it, all neighbours or the router?

[fearek]

it will be seen by anyone connected to the router (if the router sends it to them) also adding it to table manually as a static entry is better. We are almost in 2024 and this is still not fixed lmao The real workaround is using a USB ethernet card so it doesnt rely on broken wifi firmware.

[jtkDvlp]

Sry für late feedback.

@fearek thank you for explanation.

I got it working, it seems IPv6 got the kernel into panic, so I disabled it (just need IPv4) and no problems anymore. Maybe it works for someone else too

[btory]

Found a solution: https://github.com/raspberrypi/linux/issues/2522#issuecomment-2457236000

[caioycosta]

I suspect that ARP offloading by the chip, firmware, or driver is interfering with ARP requests in this setup. ARP requests sent from wireless clients are never received by the kernel—they seem to "disappear" en route. When pinging wired hosts from a wireless host, the Wi-Fi chip doesn't know about hosts on the wired network, and silently discards the ARP requests before the kernel can process and proxy them to the wired network. Enabling promiscuous mode likely disables ARP offloading, allowing the ARP requests to be received by the kernel and thus allowing ARP proxying to work.

This would explain some other reports on #2522 about ARP stopping to work when the interface MAC address was changed--the chip still "thinks" its address is the original and the ARP offload works on the original address, not the changed one--and so, changing back the address to the original MAC makes it work again.

I couldn't find any info about disabling ARP offloading on brcmfmac , so maybe promiscuous mode is actually the only way to do it in the current firmware. The downside is that whenever I need to do a tcpdump I need to remember to reenable it afterwards. I hope this sheds some light on the issue. For now, I'm enabling promiscuous mode in wlan0's post-up phase on /etc/network/interface as a semi-permanent solution.

The following text is context pertaining to my setup and how I discovered this, which may be useful on further investigations.

My setup is a bit different, I'm using a Raspberry Pi 3B as a kind of travel router, with the onboard Wi-Fi functioning simultaneously as both a wireless client (wlan0) and a wireless access point (AP), following the method described here. In addition, the AP interface (ap0) is bridged to the wired Ethernet interface (eth0).

Wired clients worked properly, but wireless clients connected to the AP experienced intermittent connectivity issues, including timeouts and "host unreachable" errors during pings. Packet captures revealed these issues were due to ARP requests not being properly forwarded between the bridged interfaces. Upon investigation, I came across this GitHub issue. Enabling promiscuous mode on wlan0 allowed ARP packets to be correctly transmitted and received across the bridge. Interestingly, despite the problem occurring on ap0, enabling promiscuous mode on ap0 had no effect; and inspecting the interfaces with ip -d link show showed promiscuity 1 on ap0, despite never explicitly enabling it. This suggests that enabling AP mode automatically enables promiscuous mode, which might be inadvertently disabled when wlan0 is brought up, as both interfaces share the same physical hardware.

In my case, I initially employed a workaround that avoided explicitly enabling promiscuous mode. Since both eth0 and ap0 are bridged (and thus typically lack individual IP addresses), I assigned the same IP address from br0 to the ap0 interface during its post-up phase using ip link set and then removed it during the wlan0 post-up phase. This method temporarily disabled ARP offloading and resolved the connectivity issues for a while. WHY this works is a total mystery, though - maybe this bumps the driver ("Oops, I'm actually an access point") and makes everything work properly. However, I've since observed that this workaround isn’t stable over the long term—after some time, likely due to events such as a DHCP lease renewal on wlan0, the ARP offload appears to be re-enabled, and the issues return. While this behavior might offer valuable clues for driver or firmware developers probing ARP offloading mechanisms, the most reliable solution still seems to be enabling promiscuous mode.