Linux Netfilter discussions
 help / color / mirror / Atom feed
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


      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