From: Jon Webb <jon_webb@binary-one.com>
To: netfilter-devel <netfilter-devel@lists.netfilter.org>
Subject: Re: Routing Questions - Netfilter Hooks
Date: Wed, 16 Apr 2003 20:48:27 -0700 [thread overview]
Message-ID: <3E9E240B.5090204@binary-one.com> (raw)
In-Reply-To: <3E9B5DCA.6010103@binary-one.com>
Ok. We've decided to either install a ficticious default route through
the loopback device, or restict our routing protocol to operation on one
subnet to which we will have a media route that will match anything of
interest. But I still have the problem of addressing routes from within
the kernel. Specifically, when I catch a packet on IP_LOCAL_OUT, I need
to check it's route with ip_route_output_key() to see if it needs
routing. Any packet which does not have a static route (ie, any packet
which used the default route) needs additional routing done to it. The
best way to do with would be to inspect the rt_flags field that is
returned in the rtable structure by ip_route_output_key() except that
they don't contain useful (if any) information. Is there another way
that I could establish which route a packet has from inside a kernel
module? Anything that distinguishes it as a default or "media" (ie
subnet) route would do the trick.
Thanks,
Jon Webb
jon_webb@binary-one.com
--------
Jon Webb
Computer Communications Research Group
University of California, Santa Cruz
Jon Webb wrote:
> Hello everyone... I am writing a new routing system. It uses a kernel
> module and a userspace daemon. Essentially the kernel module
> intercepts packets on NF_IP_PREROUTING and NF_IP_LOCAL_OUT and checks
> for existing routes. If the routes do not exist, the packets are
> bumped up to userspace so that routes can be established (by other
> means). I am having a problem for which I hope someone has a solution.
>
> To start, the documentation is unclear about when packets go to the
> kernel routing system on the outbound path. The docs indicate that
> IP_LOCAL_OUT is called before the routing code, but then there is a
> sentence that states the routing code is called "first" to determine
> source IP, etc. This has grave implications for my code because I need
> to capture all packets before they are rejected due to lack of routes!
> Right now I have verified that if I do not have a route to a host, and
> I try to ping that host, I get network unreachable messages without
> the IP_LOCAL_OUT hook ever getting called. Is there a way around this?
> Or am I just doing something wrong?
>
> My second question is more of a routing question in general, but
> perhaps someone has a suggestion. On the IP_PRE_ROUTING side, my code
> to check routes and bump them into userspace is working fine except
> that it would be really useful to know what kind of routes they are
> (ie, what flags they have). The problem with obtaining this
> information is that the rtable structure returned by the route lookup
> operation is not displaying any flags (the rt_flags field is always
> 0). This means I can't decipher whether the route it returns is a host
> route or a gateway route or whatever..
>
> Thanks,
> Jon Webb
> jon_webb@binary-one.com
>
> -----------------
> Jon Webb
> Computer Communications Research Group
> University of California, Santa Cruz
>
>
prev parent reply other threads:[~2003-04-17 3:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-15 1:18 Routing Questions - Netfilter Hooks Jon Webb
2003-04-17 3:48 ` Jon Webb [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E9E240B.5090204@binary-one.com \
--to=jon_webb@binary-one.com \
--cc=netfilter-devel@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.