Re: resolving routes externally
From: João Carlos Mendes Luís (jonny_at_jonny.eng.br)
Date: 11/23/04
- Previous message: Martin Eugen: "resolving routes externally"
- In reply to: Martin Eugen: "resolving routes externally"
- Next in thread: Joerg Sonnenberger: "Re: resolving routes externally"
- Reply: Joerg Sonnenberger: "Re: resolving routes externally"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 23 Nov 2004 11:42:39 -0200 To: Martin Eugen <martin.eugen@gmail.com>
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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: Martin Eugen: "resolving routes externally"
- In reply to: Martin Eugen: "resolving routes externally"
- Next in thread: Joerg Sonnenberger: "Re: resolving routes externally"
- Reply: Joerg Sonnenberger: "Re: resolving routes externally"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|