Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Nov 2004 11:42:39 -0200
From:      =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= <jonny@jonny.eng.br>
To:        Martin Eugen <martin.eugen@gmail.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: resolving routes externally
Message-ID:  <41A33E4F.8060705@jonny.eng.br>
In-Reply-To: <966ba91e04112301052fed8d6b@mail.gmail.com>
References:  <966ba91e04112301052fed8d6b@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help


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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41A33E4F.8060705>