Roy Marples <roy%marples.name@localhost> writes: > I am working on an issue with managing a host route to a host outside of > the defined subnet. This is basically a mess, although I can see why you want to have this work. The basic issue in the 4.4BSD stack is how arp and cloning routes work. Normally hitting a C routes is the trigger for a Lc entry (link-layer, was cloned). So somehow, there needs to be a routing entry that says "for this address, arp on this interface", and additional state to store the mac address obtained by arp. > On the other hand this works instead: > > # ifconfig fxp0 inet 10.0.0.1 > # route add -net 192.168.0.1/32 -link fxp0 -iface -cloning > # route add default -ifa 10.0.0.1 192.168.0.1 > > I have had a very unsatisfactory ad-hoc chat with a few people, so I'm > bring this here. It makes sense that it works; it sets up the cloning route that the arp code expects. Presumably you can ping the 192.168.0.1 and it will arp after just the first route. > 1) Is the route add -host command above expected to work as described in > the wiki? If so a simple fix is not to use link_addr(3) and instead set > sdl->sdl_index to the interface index. This makes it then work. > However, the kernel then displays an advisory of arpresolve: unresolved > and rt_expire == 0 so it might just be working by accident rather than > design. I don't see how it would work not to have two entries, one to trigger arp and one to store it. But maybe a L route with an empty arp RHS will trigger. I would read if_ethersubr.c to find out. > 3) Is the route add -net command a better way of describing the host > route being off the subnet net but on the link and we should update the > wiki? Good question, and probably, unless the single-entry update-RHS code for arp is ok. Have you looked at the other BSDs? (This is really about the 4.4BSD approach to arp, not about standards.)
Attachment:
pgp1WQi8MnpGh.pgp
Description: PGP signature