resolving routes externally

[Bruce M Simpson]

On Tue, Nov 23, 2004 at 11:05:06AM +0200, Martin Eugen wrote:
> At the beginning my intention was to use the routing sockets
> mechanisms, and say, to issue a 'missing route' message to some
> userland daemon capable of resolving those complex addresses (the
> resolving mechanism is generally a lookup in a local DB). But then I

You're on the right track here. You might also wish to investigate
the RTM_RESOLVE mechanism.

> realized there is no (Am I missing it?) code in the routing modules
> that could make the thread handling the packet sleep until the
> userland daemon is looking up the route. (I'm also still not sure if a
> 'netisr' thread is safe to sleep?) So I started to look at the ARP
> code, but it of course lacks the kernel - userland communication
> interface. I would appreciate any ideas about what would be the easier
> way to implement such a thing where the kernel could wait (up to some
> reasonable time-out) a userland daemon to install a new route.

If I understand correctly, you want the kernel to queue packets until
layer 2 address resolution is complete. Right now we don't do this. If
there is no route to a destination, packets will be dropped.

The ARP code implements a queue for each IP host address which is
exactly 1 mbuf long (see llinfo_arp->la_hold). This holds the most
recent packet that the host is attempting to transmit to the host
pending MAC address lookup. All other packets will be dropped.

Making a network stack thread sleep would be a Very Bad Idea. A more
appropriate approach would be to use a separate netisr queue for
packets which have pending external MAC address lookup. However,
rather than calling netisr_dispatch() directly, you would want to
call schednetisr() directly once the route resolution was complete.

I guess this is non-IP traffic, in which case making the modifications
which you need will probably be easier.

Regards,
BMS