route monitor on my system (NetBSD/i386 5.0ish) shows the LLINFO flag on arp entries generated automatically. RTM_ADD: Add Route: len 148, pid 0, seq 0, errno 0, flags: <UP,HOST,DONE,LLINFO,CLONED> locks: inits: sockaddrs: <DST,GATEWAY,IFP,IFA> [ip addr] ex0:[mac addr] [my-hostname-on-that interface] Doing arp -s [on-link-ip-addr] 1:2:3:4:5:6 RTM_ADD: Add Route: len 112, pid 14709, seq 2, errno 0, flags: <HOST,DONE,STATIC> locks: inits: <expire> sockaddrs: <DST,GATEWAY> [on-link-ip-addr] 1.2.3.4.5.6 and the entry has flags UHLS. Using the 'pub' argument to arp, I see instead RTM_ADD: Add Route: len 120, pid 18698, seq 2, errno 0, flags: <DONE,STATIC,PROTO2> locks: inits: <expire> sockaddrs: <DST,GATEWAY,NETMASK> [on-link-ip-addr] 1.2.3.4.5.6 255.255.255.255 I would run 'route -n monitor' and see what the add request looks like as it prints it. I see that RTF_ANNOUNCE is RTF_PROTO2. I am wondering if pppd is using a pre-4.4 method that doesn't work any more. There could also be an architecture-dependent bug that no one else has hit yet - ppp with proxy arp is becoming not so common. The next thing is to go through the kernel code and see if you can figure out how this is supposed to be interpreted, and to add printfs at the various EINVAL return points. (or run kgdb). See sys/net/rtsock.c and sys/net/route.c:rtrequest1 I think you want RTSOCK_DEBUG. There is also RT_DPRINTF that you could figure out how to turn on (seems permanently off, but obviously intended to do most of what you need).
Attachment:
pgpx7Q3kfC3Lt.pgp
Description: PGP signature