Re: resolving routes externally

From: João Carlos Mendes Luís (jonny_at_jonny.eng.br)
Date: 11/23/04

  • Next message: Andrey Simonenko: "Re: Tracing Disk Access"
    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"


  • Next message: Andrey Simonenko: "Re: Tracing Disk Access"

    Relevant Pages

    • resolving routes externally
      ... the network is composed of smaller ... one subnet). ... userland daemon capable of resolving those complex addresses (the ... but it of course lacks the kernel - userland communication ...
      (freebsd-hackers)
    • resolving routes externally
      ... the network is composed of smaller ... one subnet). ... userland daemon capable of resolving those complex addresses (the ... but it of course lacks the kernel - userland communication ...
      (freebsd-net)
    • Re: resolving routes externally
      ... > some details about those protocols: the network is composed of smaller ... > one subnet). ... > userland daemon capable of resolving those complex addresses (the ... but it of course lacks the kernel - userland communication ...
      (freebsd-net)
    • Re: Problems w. Promise SATA300 TX2plus PDC40775
      ... I have a Debian Sarge system with 2.6.8-K7 linux kernel (original kernel from ... Raw IP | Low Level Network Programming ... # ACPI Support ...
      (Debian-User)
    • Re: ICS questions and confusion
      ... >>>It doesn't HAVE to be on a different subnet, ... but that requires that the ICS host become a bridge. ... >> ICS is a software based NAT router, and routers work best when the ... >> network already had the required address 192.168.0.1" is confusing. ...
      (microsoft.public.windowsxp.network_web)