I'm not sure whether to blame this on the implementation of arp or on pppd for having an option it cannot fulfill.
Yesterday I created an arrangement with an OpenBSD 6.7-stable system connected directly to my LAN (call it "BSD") and another system connected to "BSD" via a PPP link over serial (the "linked system"). My original plan was to create a subnet for the linked system so that it can behave as a unique device on the LAN. To achieve this, I used pppd's "proxyarp" option which is supposed to create an ARP proxy so that devices on the LAN know to talk to "BSD" in order to reach the linked system. After setting this up, I tested the PPP link by pinging "BSD" from the linked system, which worked. Then I attempted to ping another host on the LAN, but all my pings timed out. I looked at the network traffic to see that the target was sending an ARP who-has request for the linked system but was getting no response. Obviously the ARP proxy was not working. I tried to manually add the ARP rule using arp -s, and this failed because the PPP interface is not an 802 device. If I brought down pppd, I was able to create it, but then this would create a route where all outside requests for the linked system's IP address would get stopped at "BSD"'s ethernet controller. Clearly the issue here is that ARP rules are not allowed for non-802 devices such as PPP links. My hypothesis is that this was not always the case, and some update along the way disallowed it, and this was overlooked because by that time most usage of PPP did not require ARP proxying. My proposed solutions: 1. Allow ARP proxying for non-802 devices. If there is not some security risk in doing this, this seems like the best option for ongoing compatibility. 2. Remove the "proxyarp" option from pppd. 3. Keep the "proxyarp" option, but document this issue and have pppd print a warning when it is used. Regards, David E. McMackins II
