Hi there! Some questions I couldn''t find an answer for: IPtables: - Is it possible to filter those ACK-packets (to eleminate problems with ADSL-connections) with IPtables? It wasn''t possible with IPchains, so u32 had to be used. Now there is this nice little --tcp-flags option. But I just don''t know if this is all I need. The u32 was checking for packetsize too. So if there is a eqivalent to the u32 ACK-filterrule, what would it look like? What I have found in the ML is this: ---- # Set ACK as prioritized traffic (ACK''s are less than 100 bytes) $IPTABLES -t mangle -A MANGLE_MARK -p tcp -m length --length :100 -j MARK --set-mark 1 $IPTABLES -t mangle -A MANGLE_MARK -p tcp -m length --length :100 -j RETURN ---- Wouldn''t that apply on a lot more packets than only the ACK ones? What is the exact specification of an ACK-packet? - With IPchains it was possible to mark and return in one rule. Looking at the example above this doesn''t seem possible (two -j operators). Is that right? - Can I have for example one custom chain and have forward and output send its packets to it? - Is there a howto that explains -t mangel, -A PREROUTING/POSTROUTING etc.? The only IPtables HowTo I have found is http://www.telematik.informatik.uni-karlsruhe.de/lehre/seminare/LinuxSe m/downloads/netfilter/iptables-HOWTO.html - From Patricks'' IMQ-page: ---- SFQ is very useful as a leaf qdisc. But by default, its internal queue length is 128 which is too much for small classes or even for not-so-fast links. Changing SFQ_DEPTH in net/sched/ sch_sfq.c to about 10-20 results in flows responding much faster to bandwidth changes. ---- Is that ment for SFQ in general or only in conjunction with IMQ? Thank you. Greetings, Nils
On Fri, May 03, 2002 at 04:50:18PM +0200, Nils Lichtenfeld wrote:> Hi there!Hi Nils> > Some questions I couldn''t find an answer for: > IPtables: > - Is it possible to filter those ACK-packets (to eleminate problems > with ADSL-connections) with IPtables? It wasn''t possible with IPchains, > so u32 had to be used. Now there is this nice little --tcp-flags > option. But I just don''t know if this is all I need. The u32 was > checking for packetsize too. So if there is a eqivalent to the u32 > ACK-filterrule, what would it look like? > > What I have found in the ML is this: > ---- > # Set ACK as prioritized traffic (ACK''s are less than 100 bytes) > $IPTABLES -t mangle -A MANGLE_MARK -p tcp -m length --length :100 -j > MARK --set-mark 1 > $IPTABLES -t mangle -A MANGLE_MARK -p tcp -m length --length :100 -j > RETURN > ---- > > Wouldn''t that apply on a lot more packets than only the ACK ones? What > is the exact specification of an ACK-packet?I don''t know the exact technical specification for ACK packets, but i use the example below, and it work''s (i mean as far as i can see, no "other" packets get in my $ack-queue)> > - With IPchains it was possible to mark and return in one rule. Looking > at the example above this doesn''t seem possible (two -j operators). Is > that right? >sorry, don''t know> - Can I have for example one custom chain and have forward and output > send its packets to it? >well i think so. i use constructs like these: start_ingress_iptables() { $iptables -t mangle -N IMQ_INGRESS $iptables -t mangle -A IMQ_INGRESS -m state --state ESTABLISHED -p tcp --sport ssh -j MARK --set-mark $high $iptables -t mangle -A IMQ_INGRESS -m state --state ESTABLISHED -p tcp --sport http -j MARK --set-mark $high $iptables -t mangle -A IMQ_INGRESS -m state --state ESTABLISHED -m length --length 40:100 -j MARK --set-mark $ack $iptables -t mangle -A IMQ_INGRESS -j IMQ --todev 0 $iptables -t mangle -A PREROUTING -i ${SHAPEDEV} -j IMQ_INGRESS } and i see no reason why i couln''t add something like: iptables -t mangle -A POSTROUTING -o somedevice -j IMQ_INGRESS> - Is there a howto that explains -t mangel, -A PREROUTING/POSTROUTING > etc.? The only IPtables HowTo I have found is > http://www.telematik.informatik.uni-karlsruhe.de/lehre/seminare/LinuxSe > m/downloads/netfilter/iptables-HOWTO.html >netfilter.org ?!> - From Patricks'' IMQ-page: > ---- > SFQ is very useful as a leaf qdisc. But by default, its internal queue > length is 128 which is too much for small classes or even for > not-so-fast links. Changing SFQ_DEPTH in net/sched/ sch_sfq.c to about > 10-20 results in flows responding much faster to bandwidth changes. > ---- > > Is that ment for SFQ in general or only in conjunction with IMQ? >I think it''s meant for slower links in general. btw i made the experience that SFQ_DEPTH has to be a value dividable by 8 (i use 24 and in my subjective opinion i have better interactivity)> > Thank you. > Greetings, Nils >Greetings Tobias
Hi ! I guess i have to clarify this.> - From Patricks'' IMQ-page: > ---- > SFQ is very useful as a leaf qdisc. But by default, its internal queue > length is 128 which is too much for small classes or even for > not-so-fast links. Changing SFQ_DEPTH in net/sched/ sch_sfq.c to about > 10-20 results in flows responding much faster to bandwidth changes. > ---- > > Is that ment for SFQ in general or only in conjunction with IMQ?It was meant in conjunction with IMQ and ingress shaping. The text is a bit misleading, i''m not sure if it is right. My thought was: One connection, 1 mbit rate, avg. pkt size 1480 = ~88pkt/sec. To fill up entire SFQ_DEPTH of 128 it would take 1.45 seconds. So if less bandwidth was available for this connection it would take at least this long + 1/2 rtt until package drops become noticeable for the remote side. This is probably not true as SFQ drops a (not necessary the last one!) packet from its longest slot if if queue becomes full. I had a noticable effect in combination with imq but since then changed the point at which imq tries to dequeue packets and in the mean time, i''m using it without changed SFQ_DEPTH. I saw the same advice on another page, but like said before, i''m not sure if it is true. I''m going to think about it again as soon as my head clears up ;) Bye, Patrick