From: Joel Newkirk <netfilter@newkirk.us>
To: Antony Stone <Antony@Soft-Solutions.co.uk>,
netfilter@lists.netfilter.org
Subject: Re: Packet chain traversals
Date: Fri, 1 Nov 2002 17:48:50 -0500 [thread overview]
Message-ID: <200211011748.50720.netfilter@newkirk.us> (raw)
In-Reply-To: <200210301722.g9UHMEe12082@vulcan.rissington.net>
On Wednesday 30 October 2002 12:22 pm, Antony Stone wrote:
> On Wednesday 30 October 2002 4:11 pm, Matthew G. Marsh wrote:
> > > The only thing I can think of is "which interface should this packet go
> > > out of", however that's certainly not the same sort of "decision" as
> > > there is between PREROUTING and INPUT or FORWARD, and I'm not even sure
> > > it belongs quite where it is shown...
> >
> > It does exist between OUTPUT and NAT. But the decision structure is more
> > along the lines of rule application. Thus you can issue rules such as:
> The only decisions of interest to netfilter are "is the packet local ?" and
> if not "which interface is it going out of ?". Both of those have already
> been decided in the first routing decision, between prerouting and input /
> forward.
>
> I'm not convinced there's any purpose in having another routing decision
> shown between output and postrouting, especially in a document which is
> aimed at beginners.
I'm planning to rebuild the diagram this weekend, in several forms from
simplest (in/out/forward/local) to mid (in/out/forward/natpre/natpost/local)
to full. I've not yet decided if I'm going to have 'routing decision' in the
diagram at all, since it seems that the only concrete placement of it is
after prerouting, and the existence of multiple parts in the next layer
inward (forward and input) makes the existance of SOME decision pretty
apparent. I may just wait until I have a better grasp of the interaction of
Netfilter and Iproute2 and see where my understanding leads me for a possible
generation 2 diagram. :^)
Is there some way that I can expand on Oscar's packet tracking rules to also
track when the packet hits routing? I was wondering whether I could set a
TOS in prerouting and output for testing purposes, and track incidents of
that TOS in routing.
j
prev parent reply other threads:[~2002-11-01 22:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-27 18:03 Packet chain traversals Joel Newkirk
2002-10-27 18:50 ` Oskar Andreasson
2002-10-27 19:21 ` Joel Newkirk
2002-10-27 21:23 ` Oskar Andreasson
2002-10-28 5:48 ` Joel Newkirk
2002-10-28 6:41 ` Problem With NAT to NAT with IPTABLES hare ram
2002-10-27 18:52 ` Packet chain traversals Oskar Andreasson
2002-10-28 8:32 ` Antony Stone
2002-10-28 21:18 ` Oskar Andreasson
2002-10-28 21:37 ` Antony Stone
2002-10-30 16:11 ` Matthew G. Marsh
2002-10-30 17:22 ` Antony Stone
2002-10-31 16:55 ` Matthew G. Marsh
2002-11-01 22:48 ` Joel Newkirk [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=200211011748.50720.netfilter@newkirk.us \
--to=netfilter@newkirk.us \
--cc=Antony@Soft-Solutions.co.uk \
--cc=netfilter@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox