Hello list. I''ve configured a very simple script to slow down packets coming from a particular IP Address. I''ve used IPTABLES to mark traffic coming from this IP Address, but it does not appear to be working as expected. Let me first describe my system as maybe what I''m doing is beyond what NETFILTER can do. I have one machine that runs all my servers as VM''s. The P2P WinXP box and the router are virtualized. So too is the Windows 2003 DNS server. Please have a look at the traffic control script below and let me know if I''ve done something wrong! Cheers, tkb. Below is the script. You''ll note that I''ve even tried using a filter (attached to eth0 - LAN) linking parent at eth0 going to a class on eth1 - is this even valid? tc did not seem to complain about it so I figured it must be okay. #******************************************************************* #!/bin/bash # Whole purpose of this is to slow the P2P WinXP box down! ################################### # Reset everything to known state # ################################### tc qdisc del dev eth0 root tc qdisc del dev eth1 root #################### # Setup the qdiscs # #################### tc qdisc add dev eth0 parent root handle 1: htb default 10 tc qdisc add dev eth1 parent root handle 2: htb default 10 ########################## # Setup the root classes # ########################## tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit \ ceil 10mbit tc class add dev eth1 parent 2: classid 2:1 htb rate 384kbit \ ceil 384kbit burst 15k ########################### # Setup the child classes # ########################### tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10mbit \ ceil 10mbit prio 0 tc class add dev eth1 parent 2:1 classid 2:10 htb rate 224kbit \ ceil 384kbit prio 0 tc class add dev eth1 parent 2:1 classid 2:11 htb rate 100kbit \ ceil 100kbit prio 1 tc class add dev eth1 parent 2:1 classid 2:12 htb rate 60kbit \ ceil 60kbit prio 2 ##################### # Setup the filters # ##################### # match acks the hard way, # IP protocol 6, # IP header length 0x5(32 bit words), # IP Total length 0x34 (ACK + 12 bytes of TCP options) # TCP ack set (bit 5, offset 33) ACK="tc filter add dev eth1 protocol ip parent 2:0 prio 0 u32" $ACK match ip protocol 6 0xff \ match u8 0x05 0x0f at 0 \ match u16 0x0000 0xffc0 at 2 \ match u8 0x10 0xff at 33 \ classid 2:11 #**U32_0="tc filter add dev eth0 protocol ip parent 1:0 u32" #**$U32_0 match ip src 192.168.200.163 classid 2:12 #U32_1="tc filter add dev eth1 protocol ip parent 2:0 u32" P2P="tc filter add dev eth1 protocol ip parent 2:0 prio 10" $P2P handle 1 fw classid 2:12 #################################################### # Setup the queue discipline for the child classes # #################################################### tc qdisc add dev eth1 parent 2:10 handle 10: sfq perturb 10 tc qdisc add dev eth1 parent 2:11 handle 11: sfq perturb 10 tc qdisc add dev eth1 parent 2:12 handle 12: sfq perturb 10 #************************************************************************
I''ve never tried marking packets the way that you''re doing it, so not sure if it should work. Have you tried marking with iptables instead? Something like: iptables -t mangle -A FORWARD --source 192.168.200.163 -j CLASSIFY --set-class 2:12 This will of course match all packets going both ways. Add "-i eth0" if you only want it one way. Andy Beverley On Mon, 2007-02-05 at 21:38 +1100, Anthony Kamau wrote:> Hello list. > > I''ve configured a very simple script to slow down packets coming from a > particular IP Address. I''ve used IPTABLES to mark traffic coming from this > IP Address, but it does not appear to be working as expected. Let me first > describe my system as maybe what I''m doing is beyond what NETFILTER can do. > > I have one machine that runs all my servers as VM''s. The P2P WinXP box and > the router are virtualized. So too is the Windows 2003 DNS server. > > Please have a look at the traffic control script below and let me know if > I''ve done something wrong! > > Cheers, > tkb. > > > Below is the script. You''ll note that I''ve even tried using a filter > (attached to eth0 - LAN) linking parent at eth0 going to a class on eth1 - > is this even valid? tc did not seem to complain about it so I figured it > must be okay. > > #******************************************************************* > #!/bin/bash > > # Whole purpose of this is to slow the P2P WinXP box down! > > ################################### > # Reset everything to known state # > ################################### > tc qdisc del dev eth0 root > tc qdisc del dev eth1 root > > #################### > # Setup the qdiscs # > #################### > tc qdisc add dev eth0 parent root handle 1: htb default 10 > tc qdisc add dev eth1 parent root handle 2: htb default 10 > > ########################## > # Setup the root classes # > ########################## > tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit \ > ceil 10mbit > tc class add dev eth1 parent 2: classid 2:1 htb rate 384kbit \ > ceil 384kbit burst 15k > > ########################### > # Setup the child classes # > ########################### > tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10mbit \ > ceil 10mbit prio 0 > tc class add dev eth1 parent 2:1 classid 2:10 htb rate 224kbit \ > ceil 384kbit prio 0 > tc class add dev eth1 parent 2:1 classid 2:11 htb rate 100kbit \ > ceil 100kbit prio 1 > tc class add dev eth1 parent 2:1 classid 2:12 htb rate 60kbit \ > ceil 60kbit prio 2 > > ##################### > # Setup the filters # > ##################### > # match acks the hard way, > # IP protocol 6, > # IP header length 0x5(32 bit words), > # IP Total length 0x34 (ACK + 12 bytes of TCP options) > # TCP ack set (bit 5, offset 33) > ACK="tc filter add dev eth1 protocol ip parent 2:0 prio 0 u32" > $ACK match ip protocol 6 0xff \ > match u8 0x05 0x0f at 0 \ > match u16 0x0000 0xffc0 at 2 \ > match u8 0x10 0xff at 33 \ > classid 2:11 > #**U32_0="tc filter add dev eth0 protocol ip parent 1:0 u32" > #**$U32_0 match ip src 192.168.200.163 classid 2:12 > #U32_1="tc filter add dev eth1 protocol ip parent 2:0 u32" > P2P="tc filter add dev eth1 protocol ip parent 2:0 prio 10" > $P2P handle 1 fw classid 2:12 > > #################################################### > # Setup the queue discipline for the child classes # > #################################################### > tc qdisc add dev eth1 parent 2:10 handle 10: sfq perturb 10 > tc qdisc add dev eth1 parent 2:11 handle 11: sfq perturb 10 > tc qdisc add dev eth1 parent 2:12 handle 12: sfq perturb 10 > #************************************************************************ > > > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> That''s an interesting way to mark (or should I say classify) packets with > IPTABLES. The one I''m using currently (and which I forgot to add to my > initial query) was this: > $IPTABLES -t mangle -A PREROUTING -s 192.168.200.163 -j MARK --set-mark 1To be honest, I use the MARK target as well. I just thought the CLASSIFY option would be easier in your situation because (I think) it saves an extra tc rule to classify the packets. If you''re using MARK you need a rule telling tc to classify the packets that are MARKed. I''m not sure if what you are using is correct; I use the following (you''ll need to edit appropriately): tc filter add dev ifb0 parent 1:0 prio 0 protocol ip handle 10 fw \ flowid 1:10 I''m getting out of my depth here so may be wrong, but as I understand it ''handle'' is the MARK, flowid is what it should be classified as. Andy
On Thu, 2007-02-08 at 06:52 +1100, Anthony Kamau wrote:> Thanks Andy. > > I changed ''classid'' back to ''flowid'' but whenever I run the script, it > throttles both uploads and downloads to the set rate - can you see why this > would happen by perusing my script? > > I''m thinking that the virtualization is what''s causing the problem!I don''t think the virtualization would affect it. Can you resend the iptables command you use to mark plus your tc commands? Also, can you detail your setup (for example what is on eth0 and what is on eth1). Andy
Thanks Andy. I changed ''classid'' back to ''flowid'' but whenever I run the script, it throttles both uploads and downloads to the set rate - can you see why this would happen by perusing my script? I''m thinking that the virtualization is what''s causing the problem! Cheers, Anthony. PS: Andy, please respond to this email as opposed to ther other one. I forgot to change my Outlook account before transmitting and thus ended up using the incorrect email address and message was rejected by LARTC. -----Original Message----- From: Andrew Beverley [mailto:andy@andybev.com] Sent: Thursday, 8 February 2007 4:18 To: Anthony Kamau Cc: ''LARTC'' Subject: RE: [LARTC] Problems with HTB. Help! tc filter add dev ifb0 parent 1:0 prio 0 protocol ip handle 10 fw \ flowid 1:10 I''m getting out of my depth here so may be wrong, but as I understand it ''handle'' is the MARK, flowid is what it should be classified as. Andy
> I just realized something important - I''ve been looking at > the status bar on Azureus and it appears to be broken! > Looking at the connected hosts and tallying up their > bandwidth, it is actually capped at the limit set in my HTB > script. The status bar seems to always show what the > download is capped at. However, I have seen it go to zero > when there are no connected hosts downloading from my system! > > So all this time is has been an Azureus problem!!! > > Thanks for all your help Andy. > > Cheers, > Ak. >Oh never mind - I''m high on something that I''m not aware of - it is still misbehaving! Dang it - this should be simple to implement as I''ve done it before albeit a long while back!!! Cheers, Ak.
On Thu, 2007-02-08 at 19:39 +1100, Anthony Kamau wrote:> > -----Original Message----- > > From: Andrew Beverley [mailto:andy@andybev.com] > > Sent: Thursday, 8 February 2007 7:06 > > To: Anthony Kamau > > Cc: ''LARTC'' > > Subject: RE: [LARTC] Problems with HTB. Help! > > > > > > I don''t think the virtualization would affect it. Can you resend the > > iptables command you use to mark plus your tc commands? Also, can you > > detail your setup (for example what is on eth0 and what is on eth1). > > > > Andy > > > > Thanks Andy. > > eth0 connects to my LAN network - 192.168.200.0/24 > eth1 connects to a 4 port switch then onto my ADSL modem > > I mark traffic going to my P2P server as follows: > > $IPTABLES -t mangle -A PREROUTING -i eth0 -s 192.168.200.163 \ > -j MARK --set-mark 1 > > I tried moving the rule to the FORWARD chain instead but that did not help > either: > > $IPTABLES -t mangle -A FORWARD -i eth0 -s 192.168.200.163 \ > -j MARK --set-mark 1Can you send your updated tc rules as well please? Andy
> -----Original Message----- > From: lartc-bounces@mailman.ds9a.nl > [mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Andrew Beverley > Sent: Friday, 9 February 2007 4:24 > To: Anthony Kamau > Cc: ''LARTC'' > Subject: RE: [LARTC] Problems with HTB. Help! > > Can you send your updated tc rules as well please? > > Andy >Here''s the htbinit script: ************************************************************************ #!/bin/bash # Whole purpose of this is to slow the P2P server down! ################################### # Reset everything to known state # ################################### tc qdisc del dev eth1 root #################### # Setup the links # #################### tc qdisc add dev eth1 parent root handle 2: htb default 13 ########################### # Setup the root classes # ########################### tc class add dev eth1 parent 2: classid 2:1 htb rate 384kbit \ ceil 384kbit ########################### # Setup the child classes # ########################### tc class add dev eth1 parent 2:1 classid 2:10 htb rate 224kbit \ ceil 384kbit prio 0 tc class add dev eth1 parent 2:1 classid 2:11 htb rate 100kbit \ ceil 100kbit prio 1 burst 1024k tc class add dev eth1 parent 2:1 classid 2:12 htb rate 30kbit \ ceil 30kbit prio 2 tc class add dev eth1 parent 2:1 classid 2:13 htb rate 30kbit \ ceil 30kbit prio 3 burst 1500 ##################### # Setup the filters # ##################### # match acks the hard way, # IP protocol 6, # IP header length 0x5(32 bit words), # IP Total length 0x34 (ACK + 12 bytes of TCP options) # TCP ack set (bit 5, offset 33) ACK="tc filter add dev eth1 protocol ip parent 2:0 prio 0 u32" $ACK match ip protocol 6 0xff \ match u8 0x05 0x0f at 0 \ match u16 0x0000 0xffc0 at 2 \ match u8 0x10 0xff at 33 \ flowid 2:11 U32="tc filter add dev eth1 protocol ip parent 2:0 u32" $U32 match ip src 192.168.200.130 flowid 2:10 $U32 match ip src 192.168.200.140 flowid 2:10 $U32 match ip src 192.168.200.147 flowid 2:10 P2P="tc filter add dev eth1 parent 2:0 prio 2 protocol ip" #$P2P handle 1 fw flowid 2:12 #################################################### # Setup the queue discipline for the child classes # #################################################### tc qdisc add dev eth1 parent 2:10 handle 10: sfq perturb 10 tc qdisc add dev eth1 parent 2:11 handle 11: sfq perturb 10 tc qdisc add dev eth1 parent 2:12 handle 12: sfq perturb 10 ********************************************************************** And here is the rule in the firewall that is marking the parkets: ************************************************************************ $IPTABLES -t mangle -I FORWARD -s $P2PSRVR -i $LAN_IFACE -j MARK \ --set-mark 1 ************************************************************************ Can you spot any issues with this? In the mean time, I''ll try your classid method and if that works fine, then so be it from now on. Cheers, tkb.
On Fri, 2007-02-09 at 20:52 +1100, tkb2766 wrote:> > -----Original Message----- > > From: lartc-bounces@mailman.ds9a.nl > > [mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Andrew Beverley > > Sent: Friday, 9 February 2007 4:24 > > To: Anthony Kamau > > Cc: ''LARTC'' > > Subject: RE: [LARTC] Problems with HTB. Help! > > > > Can you send your updated tc rules as well please? > > > > Andy > > > > Here''s the htbinit script: > ************************************************************************ > #!/bin/bash > > # Whole purpose of this is to slow the P2P server down! > > ################################### > # Reset everything to known state # > ################################### > tc qdisc del dev eth1 root > > #################### > # Setup the links # > #################### > tc qdisc add dev eth1 parent root handle 2: htb default 13 > > ########################### > # Setup the root classes # > ########################### > tc class add dev eth1 parent 2: classid 2:1 htb rate 384kbit \ > ceil 384kbit > > ########################### > # Setup the child classes # > ########################### > tc class add dev eth1 parent 2:1 classid 2:10 htb rate 224kbit \ > ceil 384kbit prio 0 > tc class add dev eth1 parent 2:1 classid 2:11 htb rate 100kbit \ > ceil 100kbit prio 1 burst 1024k > tc class add dev eth1 parent 2:1 classid 2:12 htb rate 30kbit \ > ceil 30kbit prio 2 > tc class add dev eth1 parent 2:1 classid 2:13 htb rate 30kbit \ > ceil 30kbit prio 3 burst 1500 > > ##################### > # Setup the filters # > ##################### > # match acks the hard way, > # IP protocol 6, > # IP header length 0x5(32 bit words), > # IP Total length 0x34 (ACK + 12 bytes of TCP options) > # TCP ack set (bit 5, offset 33) > ACK="tc filter add dev eth1 protocol ip parent 2:0 prio 0 u32" > $ACK match ip protocol 6 0xff \ > match u8 0x05 0x0f at 0 \ > match u16 0x0000 0xffc0 at 2 \ > match u8 0x10 0xff at 33 \ > flowid 2:11 > U32="tc filter add dev eth1 protocol ip parent 2:0 u32" > $U32 match ip src 192.168.200.130 flowid 2:10 > $U32 match ip src 192.168.200.140 flowid 2:10 > $U32 match ip src 192.168.200.147 flowid 2:10 > P2P="tc filter add dev eth1 parent 2:0 prio 2 protocol ip" > #$P2P handle 1 fw flowid 2:12 > > #################################################### > # Setup the queue discipline for the child classes # > #################################################### > tc qdisc add dev eth1 parent 2:10 handle 10: sfq perturb 10 > tc qdisc add dev eth1 parent 2:11 handle 11: sfq perturb 10 > tc qdisc add dev eth1 parent 2:12 handle 12: sfq perturb 10 > ********************************************************************** > > And here is the rule in the firewall that is marking the parkets: > ************************************************************************ > $IPTABLES -t mangle -I FORWARD -s $P2PSRVR -i $LAN_IFACE -j MARK \ > --set-mark 1 > ************************************************************************ > > > Can you spot any issues with this? > > In the mean time, I''ll try your classid method and if that works fine, then > so be it from now on.I see the problem. You''re using a default of 13 so all unclassified traffic goes to classid 13. All traffic from and to 192.168.200.163 falls into this category, and is therefore limited to 30 kbit. I suggest changing your default to 10, removing the U32 rules to match all the other hosts, and using -j CLASSIFY --set-class 2:13 on your iptables rule (the current one based on MARK isn''t used at the minute anyway because there is no tc filter for it). Hope this helps, Andy Beverley
> -----Original Message----- > From: Andrew Beverley [mailto:andy@andybev.com] > Sent: Saturday, 10 February 2007 0:01 > To: tkb2766 > Cc: ''LARTC'' > Subject: RE: [LARTC] Problems with HTB. Help! > > > I see the problem. You''re using a default of 13 so all unclassified > traffic goes to classid 13. All traffic from and to 192.168.200.163 > falls into this category, and is therefore limited to 30 kbit. > > I suggest changing your default to 10, removing the U32 rules to match > all the other hosts, and using -j CLASSIFY --set-class 2:13 on your > iptables rule (the current one based on MARK isn''t used at the minute > anyway because there is no tc filter for it). > > Hope this helps, > > Andy Beverley >Could it be too that Kernel 2.6.19-2 I recently upgraded to might have a problem???
On Sat, 2007-02-10 at 10:36 +1100, tkb2766 wrote:> > -----Original Message----- > > From: Andrew Beverley [mailto:andy@andybev.com] > > Sent: Saturday, 10 February 2007 0:01 > > To: tkb2766 > > Cc: ''LARTC'' > > Subject: RE: [LARTC] Problems with HTB. Help! > > > > I see the problem. You''re using a default of 13 so all unclassified > > traffic goes to classid 13. All traffic from and to 192.168.200.163 > > falls into this category, and is therefore limited to 30 kbit. > > > > I suggest changing your default to 10, removing the U32 rules to match > > all the other hosts, and using -j CLASSIFY --set-class 2:13 on your > > iptables rule (the current one based on MARK isn''t used at the minute > > anyway because there is no tc filter for it). > > > > Hope this helps, > > > > Andy Beverley > > > > I''ve already tried what you suggest and it did not work.Can you send your modified rules then that you say still ''did not work''? Your scripts as previously sent would definitely show the behaviour you describe, ie all unmatched traffic (including your p2p machine both ways) rate limited to 30kbit> I also do not have > the capability to use CLASSIFY in IPTABLES - what module provides this > functionalty?Not sure what the module''s called, but it''s "CLASSIFY target support" in the kernel menuconfig (CONFIG_NETFILTER_XT_TARGET_CLASSIFY in the kernel config file) If you haven''t got it just use MARK, but you''ll need the extra filter lines for tc.
On Sat, 2007-02-10 at 12:08 +1100, tkb2766 wrote:> > -----Original Message----- > > From: Andrew Beverley [mailto:andy@andybev.com] > > Sent: Saturday, 10 February 2007 0:01 > > To: tkb2766 > > Cc: ''LARTC'' > > Subject: RE: [LARTC] Problems with HTB. Help! > > > > > > I see the problem. You''re using a default of 13 so all unclassified > > traffic goes to classid 13. All traffic from and to 192.168.200.163 > > falls into this category, and is therefore limited to 30 kbit. > > > > I suggest changing your default to 10, removing the U32 rules to match > > all the other hosts, and using -j CLASSIFY --set-class 2:13 on your > > iptables rule (the current one based on MARK isn''t used at the minute > > anyway because there is no tc filter for it). > > > > Hope this helps, > > > > Andy Beverley > > > > Could it be too that Kernel 2.6.19-2 I recently upgraded to might have a > problem???No I doubt it. Like I said in the previous post, the rules that you sent would show the behaviour described, with a correctly functioning system
> > > > Can you send your modified rules then that you say still ''did > > not work''? > > Below is how I now have it: > ====================================================================> #!/bin/bash > > # Whole purpose of this is to slow the P2P server down! > > ################################### > # Reset everything to known state # > ################################### > tc qdisc del dev eth0 root > tc qdisc del dev eth1 root > > #################### > # Setup the links # > #################### > tc qdisc add dev eth0 parent root handle 1: htb default 10 > tc qdisc add dev eth1 parent root handle 2: htb default 10 > > ########################### > # Setup the root classes # > ########################### > tc class add dev eth1 parent 2: classid 2:1 htb rate 384kbit ceil 384kbit > > ########################### > # Setup the child classes # > ########################### > tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10mbit ceil 10mbit > prio 0 > tc class add dev eth1 parent 2:1 classid 2:10 htb rate 224kbit ceil 384kbit > prio 0 > tc class add dev eth1 parent 2:1 classid 2:11 htb rate 100kbit ceil 100kbit > prio 1 > tc class add dev eth1 parent 2:1 classid 2:12 htb rate 60kbit ceil 60kbit > prio 2 > > ##################### > # Setup the filters # > ##################### > # match acks the hard way, > # IP protocol 6, > # IP header length 0x5(32 bit words), > # IP Total length 0x34 (ACK + 12 bytes of TCP options) > # TCP ack set (bit 5, offset 33) > ACK="tc filter add dev eth1 protocol ip parent 2:0 prio 1 u32" > $ACK match ip protocol 6 0xff \ > match u8 0x05 0x0f at 0 \ > match u16 0x0000 0xffc0 at 2 \ > match u8 0x10 0xff at 33 \ > flowid 2:11 > U32="tc filter add dev eth1 protocol ip parent 2:0 prio 1 u32" > $U32 match ip src 192.168.200.163 match ip sport 6881 0xffff flowid 2:12I couldn''t get this line to work either - maybe someone else can help as I''ve never used u32 myself. However, replacing it with: iptables -t mangle -A FORWARD -o eth1 --source 10.0.14.250 -p tcp \ --sport 6881 -j CLASSIFY --set-class 2:12 seems to do the trick. You''ll need to change tcp to udp if it''s UDP that you want to match rather than TCP.
> -----Original Message----- > From: Andrew Beverley [mailto:andy@andybev.com] > Sent: Saturday, 10 February 2007 23:04 > To: tkb2766 > Cc: ''LARTC'' > Subject: RE: [LARTC] Problems with HTB. Help! > > > iptables -t mangle -A FORWARD -o eth1 --source 10.0.14.250 -p tcp \ > --sport 6881 -j CLASSIFY --set-class 2:12 > > seems to do the trick. > > You''ll need to change tcp to udp if it''s UDP that you want to match > rather than TCP. >I tried using the CLASSIFY target in IPTABLES, but it errors out with the following: ************* iptables v1.2.8: Unknown arg `--set-class'' Try `iptables -h'' or ''iptables --help'' for more information. ************* Do I need to installer a later version of IPTABLES? Cheers, tkb.
> > > > > > iptables -t mangle -A FORWARD -o eth1 --source 10.0.14.250 -p tcp \ > > --sport 6881 -j CLASSIFY --set-class 2:12 > > > > seems to do the trick. > > > > You''ll need to change tcp to udp if it''s UDP that you want to match > > rather than TCP. > > > > I tried using the CLASSIFY target in IPTABLES, but it errors out with the > following: > ************* > iptables v1.2.8: Unknown arg `--set-class'' > Try `iptables -h'' or ''iptables --help'' for more information. > ************* > > Do I need to installer a later version of IPTABLES?Hmmm not sure. No harm in upgrading I guess - I use 1.3.6 ftp://ftp.netfilter.org/pub/iptables/iptables-1.3.6.tar.bz2
On Sun, 2007-02-11 at 00:21 +1100, tkb2766 wrote:> > -----Original Message----- > > From: Andrew Beverley [mailto:andy@andybev.com] > > Sent: Saturday, 10 February 2007 23:27 > > To: tkb2766 > > Cc: ''LARTC'' > > Subject: RE: [LARTC] Problems with HTB. Help! > > > > > > Hmmm not sure. No harm in upgrading I guess - I use 1.3.6 > > > > ftp://ftp.netfilter.org/pub/iptables/iptables-1.3.6.tar.bz2 > > > > > > I went one version higher (1.3.7) and now all seems to be well with the > CLASSIFY target. > > However, why my HTB script isn''t working still puzzles me and I''ll keep at > it until I figure out why.I suggest you temporarily change the CLASSIFY to a LOG. This will confirm that you''re matching packets as you expect. Look at the kernel log file to check you''re capturing as expected once you''ve made the change.> It could still be a kernel issue as there is > mention of compilation issues with kernel 2.6.19 at: > http://www.netfilter.org/news.html#2006-12-04 - see comment on 2006-Dec-04.I still doubt it''s a kernel issue to be honest.
> -----Original Message----- > From: Andrew Beverley [mailto:andy@andybev.com] > Sent: Sunday, 11 February 2007 0:33 > To: tkb2766 > Cc: ''LARTC'' > Subject: RE: [LARTC] Problems with HTB. Help! > > I still doubt it''s a kernel issue to be honest. >I updated to IPTABLES ver 1.3.7 and now I can --set-class. However, that has not made any difference to my situation - traffic still affected in both directions! I''ve now read several posts about HTB not working as expected - me thinks someone has gone and broken something! I might resort to going back to previous Kernel version to get my HTB working again! Cheers, tkb.