Rob,
Thanks for your reply! It's very good!
In fact my problem is simpler to you( the
last email is not clear):
Now I create a raw socket(SOCK_RAW) on a local machine, construct
a ICMP packet and send it out. So what queues will this packet go through?
I tested it and it seems that this packet first goes to OUTPUT
queue. is that right? If so, then ip stack's interface to RAW socket
should be below the function of appending IP header to a transport layer
datagram but above the routing decision function and also above the
OUTPUT queue, am I right?
Thanks!
Fu
Xinwen Fu
On Sun, 3 Feb 2002, Rob Landley wrote:
> On Sunday 03 February 2002 01:45 pm, Xinwen - Fu wrote:
> > Hi, All,
> >
> > I want to know how a raw packet passes the chain of iptables.
> >
> > Here are the iptables chains
> >
> > --->PRE------>[ROUTE]--->FWD---------->POST------>
> > Conntrack | Filter ^ NAT (Src)
> > Mangle | | Conntrack
> > NAT (Dst) | [ROUTE]
> > (QDisc) v |
> > IN Filter OUT Conntrack
> >
> > | Conntrack ^ Mangle
> > |
> > | | NAT (Dst)
> >
> > v | Filter
> >
> >
> > So how a raw packet go through these chains?
>
>
> Well, from trial and error and a lot of documentation reading, I eventually
> worked out that a TCP/IP packet basically seems to do this:
>
> --->pre--->forward--->post--->
> | ^
> | |
> v |
> input->local ports->output
>
> I'd like to point out that the last arrow should point from "output" to
> "post", since kmail apparently is not using a fixed with font, and I can't
> figure out how to get it to do so. (I did figure out how to get it to use a
> korean, chinese, or cyrillic encoding, but not monospaced. Sigh...)
>
> So in prerouting, the packet is either forwarded on to the forwarding chain
> (if it's not for this box) or to the input chain (if it's for a daemon on
> this box). Forwarding never sees packets locally generated on this box, they
> go into the output chain and then get sent on to postrouting (which is where
> forwarding also feeds into).
>
> It took a little trial and error to work this out, by the way. It's entirely
> ossibly I'm wrong (since I don't think the above agrees with the
> documentation), but at the same time it works and survives specific behavior
> testing, so... :) The tables are fairly arbitrarily broken into "NAT" tables
> and non-NAT tables. Oh, and one of the chains (output, I think) exists in
> both nat and non-nat versions. To this day, I have no idea why...
>
> > Thanks!!
> >
> > Xinwen Fu
>
> If the above doesn't help, this might:
>
> http://netfilter.samba.org/unreliable-guides/
>
> Rob
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:30 EST