raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.18k stars 5.02k forks source link

Wifi interface replies on arp requests only in promiscuous mode #2677

Open ingo-h opened 6 years ago

ingo-h commented 6 years ago

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 commented 5 years ago

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

jrcichra commented 5 years ago

sudo ifconfig wlan0 promisc

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

jrcichra commented 5 years ago

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

JamesH65 commented 5 years ago

rc.local is probably the best approach.

Closing this issue as questions answered/issue resolved.

DTMW2 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

We are in 2022 and this is STILL not fixed

JamesH65 commented 2 years ago

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 commented 2 years ago

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

ericofusco commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 week ago

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