resolving routes externally
João Carlos Mendes Luís
jonny at jonny.eng.br
Tue Nov 23 05:42:43 PST 2004
Martin Eugen wrote:
> Hi there,
> I'm currently trying to implement some networking protocols in the
> kernel. I would like to ask a few questions, but first, let me explain
> some details about those protocols: the network is composed of smaller
> subnets connected through gateways. Hosts have a fairly complex global
> addresses, and small integer subnet addresses (that are valid only in
> one subnet). Global routing is done at gateways, that upon reception
> of a packet perform some lookups based on the complex global address
> of the recipient in order to find the subnet and the small integer
> address of the next hop. May be it would be easier to understand if
> you imagine the internet as a network where IP addresses are not
> global, but hostnames are. IP packets that need to be routed outside
> of given subnet will carry hostnames instead of ip addresses, and
> gateways will do some resolving based on the domain or something of
> the destination hostname in order to find the next hop.
> 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
> 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.
Why don´t you simply discard the packet and wait for the next retry?
> P.S. I'm not subscribed to the list, please CC any replies.
More information about the freebsd-hackers
mailing list