I have a not so new PC on which I installed Ubuntu 24.04 LTS. It does not have WiFi connectivity, and I do not have a wired internet connection. Therefore, I would like to endow it an internet access through a Raspberry Pi, which can connect to a WiFi hotspot. I would connect the PC with the Raspberry by means of Ethernet. The Raspberry has Raspberry Pi OS Bookworm, and it gets the IP dynamically on the wlan0 interface. Instead, on its Ethernet eth0 interface I set the static IP 172.16.10.105 and subnet mask 255.255.255.0. On the other hand, the Ethernet interface enp4s0 on the old PC is set with the static IP 172.16.10.104, subnet mask 255.255.255.0, and gateway 172.16.10.105 (this is the IP of the eth0 interface of the Raspberry). The eth0 interface of the Raspberry and the enp4s0 of the Ubuntu PC are connected through an Ethernet cable. To realize the bridge to share the internet access, on the Raspberry I enabled the IP forwarding by uncommenting the line net.ipv4.ip_forward=1 in the file /etc/sysctl.conf, and I used parprouted as follows: sudo parprouted -d eth0 wlan0 To monitor what happens on the eth0 interface of the Raspberry, I ran: sudo tcpdump --interface eth0 The ping from the old PC to the Raspberry is ok, but when I try to access internet from the old PC (as an example, with curl https://stackoverflow.com ) it fails, and both tcpdump and parprouted seem to indicate that the Raspberry did not receive anything. Here you can find the output of both tcpdump and parprouted (I just substituted a few IP and MAC addresses as a caution): log files They recorded the activity due to the ping, but they recorded nothing when I run the curl command. What am I missing? Thanks a lot.

I am working on a PDP-10 emulator (see https://github.com/Rhialto/klh10 ). The operating system installed inside it may want to communicate with the outside world via IPv4 (which was just gaining use when those machines were popular). For this purpose, the emulator opens a packet filter (or alternatively, a tap device) on the host machine. Suppose you're on a local network, 10.0.0.x. The emulated OS may use an IPv4 address of, say, 10.0.0.51. In order for other hosts on the same network to be able to communicate with the virtual host, they send ARP requests for 10.0.0.51. I want the Unix kernel to answer these requests for me with a sensible ethernet address (which is called proxy-ARP). To make the Unix do this, the emulator does (the equivalent of) "arp -s 10.0.0.51 01:23:45:56:78:9A pub", where the ethernet address of the host OS is used. On other Unixen than Linux, this has the desired effect. If I attempt to telnet, or ping, to 10.0.0.51 I see the ARP requests go out for the emulated host, and replies come back: 23:13:42.391941 ARP, Request who-has 10.0.0.51 tell 10.0.0.16, length 46 23:13:42.391954 ARP, Reply 10.0.0.51 is-at f6:2b:a4:a0:76:b0 (oui Unknown), length 28 However, on Linux (I have Ubuntu 15.10), this does not work. The entry does show up in the ARP table with "arp -a", although in a weird way: ? (10.0.0.51) at PERM PUB on eth0 I have tried a few seemingly related sysctls to try to enable the proxy ARPing, such as net.ipv4.conf.all.proxy_arp = 1 net.ipv4.conf.default.proxy_arp = 1 net.ipv4.conf.eth0.proxy_arp = 1 and even net.ipv4.ip_forward = 1 but none of this helps. What am I missing? I can test this just using the arp command on the Linux box, a tcpdump for observation, and another box to initiate ARP requests. When I get it to work, I can install any necessary extra setup steps into the emulator. EDIT: here is a simple scenario to try, if you have 2 machines on the same network, one of which is Linux: 1. On the Linux box, do sudo arp -s 10.0.0.51 01:23:45:56:78:9A pub. You may need to substitute a different IP address if you're using a different local network; the address should not exist but fit inside your network. 192.168.0.51 could be a possibility. Also, I noticed that Ubuntu refused to accept random ethernet addresses, so you may need to substitute an ethernet address of the eth0 interface. 2. On the same or other box, sudo tcpdump -i eth0 arp. This will show all ARP requests and replies on the network. 3. On some other box, which may be a different operating system altogether, do ping 10.0.0.51 (or the address you used, of course). Expected result: the running tcpdump command should show ARP Requests and ARP Replies. If it doesn't, I would like to know what setting is needed to make it happen. And if this is Ubuntu-specific perhaps. The ping will ultimately fail (no host by that IP address is available) but that is immaterial in this test. If it says ping: sendto: Host is down it means it knows there is no ARP Reply.

**edit:** I have found that this is a duplicate of [Why ARP Response only when network adapter in promiscuous mode?](https://superuser.com/q/1298232/879258) . ---- I use a Raspberry Pi 3B+ with Rasbian Stretch and set it up with proxy arp following the tutorial from Debian: [Bridging Network Connections with Proxy ARP](https://wiki.debian.org/BridgeNetworkConnectionsProxyArp) to "bridge" eth0 to wlan0. According to this it is easy to set up proxy arp with: rpi3 ~# echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp rpi3 ~# echo 1 > /proc/sys/net/ipv4/ip_forward rpi3 ~# ip route add 192.168.10.60/32 dev eth0 192.168.10.60 is the client on eth0 that should be "bridged" to wlan0. But it doesn't work. I have to enable promiscuous mode on wlan0 to get it to work but could not find any hints to do this. rpi3 ~# ip link set wlan0 promisc on Is promiscuous mode needed for Stretch? If not, how can I avoid it? **updates:** Checked that rp_filter is set to 0. hostapd is not installed. wlan0 is in client mode and managed by wpa_supplicant.

I would like to add ARP entry for an entire subnet (10.50.0.0/16). I tried : arp -v -i p4p1 -s 10.50.0.0 MAC_OF_P4P2 netmask 255.255.0.0 pub But the command returns: arp: SIOCSARP() SIOCSARP: Invalid argument No problem if I add one by one: arp -v -i p4p1 -s 10.50.0.1 MAC_OF_P4P2 Is there any way to do what I want ? Something like: arp -v -i p4p1 -s 10.50.0.0/16 MAC_OF_P4P2 # **Story:** I have 3 interfaces: eth0, p4p1 and p4p2. p2p1 and p2p2 are connected through a device but let's say like a wire. We have multiple servers with A.B.x.x in the network that is connected to Eth0. ### From the system, I would like to access to A.B.x.x: 1. Through Eth0 directly: ping A.B.X.X **no problem**, it does automatically 2. Through p2p1 -> external device/wire -> p2p2 and then redirect to Eth0 : ping 10.50.X.X In that case, I need to create virtual IPs 10.50.0.0/16 that will be same as A.B.0.0/16 but through the p4p* interfaces. Packets need to keep 10.50.x.x as IP source/destination, only when it reaches eth0, the IP will be translated to A.B.X.X. Let's do it step by step. 1. I route 10.50.0.0/16 to my interface p4p1: ip route add 10.50.0.0/16 dev p2p1. ## => p4p1 doesn't know Who has 10.50.0.152? Tell 10.0.0.1 ### I need to set an ARP entry to link 10.50.0.0/16 to p4p2.

Am trying to enable proxy arp for some of the interfaces, with the normal interface name eth0, eth1, etc [root@eth2.1]# sysctl net.ipv4.conf.eth0.proxy_arp 0 But for interface names such as "eth1.11, eth2.1" its giving the below error. Tried different format "", '' etc. but no help. [root@eth2.1]# sysctl net.ipv4.conf.eth2.1.proxy_arp error: "net.ipv4.conf.eth2\.1.proxy_arp" is an unknown key can anyone please point out the correct way to do this ?

I'm scratching my head about this question... I have a debian squeeze machine that is connected to an internal lab network. We have a lot of machines that have default proxy-arp configurations on them, and occasionally one of those machines starts hijacking a lot of lab addresses. After resolving the latest Proxy-ARP incident which brought down most of our lab, I found a few residual entries like this in /var/log/syslog (below). For those not accustomed to reading arpwatch logs, the machine that owns 00:11:43:d2:68:65 is fighting with 192.168.12.102 and 192.168.12.103 about who owns those address. Sep 13 14:25:27 netwiki arpwatch: flip flop 192.168.12.103 00:11:43:d2:68:65 (84:2b:2b:4b:71:b4) eth0 Sep 13 14:26:24 netwiki arpwatch: flip flop 192.168.12.103 84:2b:2b:4b:71:b4 (00:11:43:d2:68:65) eth0 Sep 13 14:29:03 netwiki arpwatch: flip flop 192.168.12.102 00:26:b9:4e:d3:71 (00:11:43:d2:68:65) eth0 Sep 13 14:29:03 netwiki arpwatch: flip flop 192.168.12.102 00:11:43:d2:68:65 (00:26:b9:4e:d3:71) eth0 The very alarming thing is that 00:11:43:d2:68:65 belongs to the same machine I was running arpwatch on... First, I validated that /proc/sys/net/ipv4/conf/eth0/proxy_arp is 0. Next, I used tshark to validate that my machine really is spoofing ARPs to others... [mpenning@netwiki ~]$ ip addr show eth0 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:11:43:d2:68:65 brd ff:ff:ff:ff:ff:ff inet 192.168.12.239/24 brd 192.168.12.255 scope global eth0 inet6 fe80::211:43ff:fed2:6865/64 scope link valid_lft forever preferred_lft forever [mpenning@netwiki ~]$ [mpenning@netwiki ~]$ arp -an ? (192.168.12.46) at 00:15:c5:f5:81:9d [ether] on eth0 ? (192.168.12.236) at 00:1e:c9:cd:46:c8 [ether] on eth0 ? (10.211.180.1) at 00:1e:49:11:fe:47 [ether] on eth1 ? (192.168.12.20) at f0:4d:a2:02:81:66 [ether] on eth0 [mpenning@netwiki ~]$ cat /proc/sys/net/ipv4/conf/eth0/proxy_arp 0 [mpenning@netwiki ~]$ sudo tshark -i eth0 arp and ether src 00:11:43:d2:68:65 Running as user "root" and group "root". This could be dangerous. Capturing on eth0 0.000000 Dell_d2:68:65 -> Dell_02:81:66 ARP 192.168.12.102 is at 00:11:43:d2:68:65 84.954989 Dell_d2:68:65 -> Dell_f5:81:9d ARP 192.168.12.103 is at 00:11:43:d2:68:65 [mpenning@netwiki ~]$ uname -a Linux netwiki 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 GNU/Linux [mpenning@netwiki ~]$ The facts are undeniable. I have a debian box that is spoofing ARPs and I have no idea why. I am the only user on this machine, I run fail2ban to prevent brute-force attacks, and it's on an internal lab network behind a door that requires a badge for entry; I highly doubt it has been hacked. Three questions... 1. First, is there any cause I may have missed? What steps should I use to isolate whether this is an application or kernel problem? 2. If this is a kernel bug, which mailing-list should I report it on? FYI, the normal [kernel.org bug reporting tool](http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html) seems to be down right now. 3. Is there anything I can do to to solve the problem other than waiting for a patch?