Hi, I haven't the output of the "ls" with me. The packet was fragment in three parts, and I send 40 packets and I can see 40 packets in the filter, 80 in the qdisc and 40 in the Iptables rule (mangle dscp). So, for me me Ingress QoS takes place before the NAT and the mangle table.
I made other tests and I think I identified where the re-assembly of fragment packet is made. I put a simple Iptables rule (mangle dscp) and I verify the conntrack was disable (unload the module). I send 40 packets fragmented in two parts in the interface eth0 (MTU 1000 and packets size 1028). The counter of the Iptables rule count 80 packets and the packets go out by the eth1 interface (MTU 1500) but the packets stay fragmented. If try this test with the conntrack module loaded, the counter of Iptables rule count 40 packets and the packets are re-assembled when they go out by the eth1 interface. So, I think it's the conntrack system which re-assemble the fragmented packet. 2007/7/2, nano bug <[EMAIL PROTECTED]>:
Hello, Can you post a "tc -s -d filter ls dev nas0" ? On 7/2/07, Edouard Thuleau <[EMAIL PROTECTED]> wrote: > > Yes, > This one was for the DSCP re-marking : > > iptables -t mangle -A PREROUTING -i nas0 -d 192.168.43.2 -j DSCP > --set-dscp 0x08 > > $TC qdisc add dev nas0 handle ffff: ingress > $TC filter add dev nas0 parent ffff: protocol ip prio 1 u32 match ip > tos 0x20 0xff police rate 200kbit burst 1k drop flowid :1 > > and this one with a DNAT rule : > > iptables -t nat -A PREROUTING -i nas0 -p udp --dport 11112 -j DNAT > --to-destination 192.168.1.10 > > $TC qdisc add dev nas0 handle ffff: ingress > $TC filter add dev nas0 parent ffff: protocol ip prio 1 u32 match ip > dst 192.168.1.10 police rate 200kbit burst 1k drop flowid :1 > > > 2007/7/2, nano bug <[EMAIL PROTECTED] >: > > > > Hello, > > > > Can you post the scripts you are using ? > > > > On 7/2/07, Edouard Thuleau <[EMAIL PROTECTED] > wrote: > > > > > > Thanks, > > > I know the older version of this diagram and this one is quite the > > > same I told below but the problem is the same for the DNAT. I made another > > > test. I change the DSCP value in the PREROUTING table and I put an ingress > > > policing which match this new dscp value but the filter doesn't match > > > nothing (I work on a Linux 2.6.17). > > > With my test, the older version (http://www.imagestream.com/~josh/PacketFlow.jpg<http://www.imagestream.com/%7Ejosh/PacketFlow.jpg>) > > > of the diagram seams more exactly. > > > > > > Have you an idea ? > > > > > > 2007/7/2, nano bug < [EMAIL PROTECTED] >: > > > > > > > > Hello, > > > > > > > > I find this one more useful : > > > > > > > > http://www.imagestream.com/~josh/PacketFlow-new.png<http://www.imagestream.com/%7Ejosh/PacketFlow-new.png> > > > > > > > > On 7/2/07, Edouard Thuleau <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi, > > > > > > > > > > I find this diagram which details the kernel packet traveling : > > > > > http://www.docum.org/docum.org/kptd/ > > > > > Is it up to date ? > > > > > I made some test and I put a DNAT rules in the PREROUTING table > > > > > of an interface and I attach it a ingress policy, the dst IP wasn't changed. > > > > > the DNAT it isn't yet make. > > > > > > > > > > I've another question (I'm not sure is it the good mailing > > > > > list), for the fragment packet, I see the ingress policy doesn't work > > > > > correctly and I'd like to know where in the kernel travel of the packet the > > > > > fragment are re-assemble ? At the NAT or in the routing ? > > > > > > > > > > Thanks, > > > > > Edouard. > > > > > > > > > > _______________________________________________ > > > > > LARTC mailing list > > > > > [email protected] > > > > > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > > > > > > > > > > > > > > > > > > >
_______________________________________________ LARTC mailing list [email protected] http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
