Hello all,
I am trying to make a filter into my QoS rules and I founded that
when I try to use filters u32 and with fwmark they do not work together.
This is the filter I use, just and example, for u32:
$TC filter add dev $DL parent 1:0 protocol ip prio 1 u32 match ip sport
22 0xffff flowid 1:10
This is working fine. Now if I try to mark a package that I want it
to go to the same class (1:10) it get an error:
$IPT -t mangle -A PREROUTING -s 200.163.208.4 -j MARK --set-mark 10
Then I tryed to make the filter for this:
$TC filter add dev $DL parent 1:0 protocol ip prio 1 handle 10 fw
classid 1:10
RETURNS:
[root@ns1 rc.d]# /sbin/tc filter add dev eth3 parent 1:0 protocol ip
prio 1 handle 10 fw classid 1:10
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
[root@ns1 rc.d]#
Anyone knows what can I do? My full script (the one that is working
fine is at the end).
Att,
Nataniel Klug
------
#!/bin/sh
#------
# Script de QoS Cyber Nett
#------
# Nataniel Klug
# suporte@cnett.com.br
#------
TC="/sbin/tc"
IPT="/usr/local/sbin/iptables"
DL="eth3"
#------
# Apagando regras antigas de QoS
#------
$TC qdisc del dev $DL root 2> /dev/null > /dev/null
$TC qdisc del dev $DL ingress 2> /dev/null > /dev/null
#------
# Regras para a placa eth1
#------
$TC qdisc add dev $DL root handle 1: htb default 50
CLASS="/sbin/tc class add dev $DL parent"
$CLASS 1: classid 1:1 htb rate 3072Kbit
$CLASS 1:1 classid 1:10 htb rate 256Kbit prio 1
$CLASS 1:1 classid 1:20 htb rate 1024Kbit ceil 2048Kbit prio 2
$CLASS 1:1 classid 1:30 htb rate 512Kbit ceil 512Kbit prio 3
$CLASS 1:1 classid 1:40 htb rate 512Kbit ceil 512Kbit prio 3
$CLASS 1:1 classid 1:50 htb rate 512Kbit ceil 512Kbit prio 4
QDISC="/sbin/tc qdisc add dev $DL parent"
$QDISC 1:10 handle 10: sfq perturb 10
$QDISC 1:20 handle 20: sfq perturb 10
$QDISC 1:30 handle 30: sfq perturb 10
$QDISC 1:40 handle 40: sfq perturb 10
$QDISC 1:50 handle 50: sfq perturb 10
FILTER="/sbin/tc filter add dev $DL parent 1:0 protocol ip prio 1 u32"
$FILTER match ip protocol 1 0xff flowid 1:10
$FILTER match ip sport 22 0xffff flowid 1:10
$FILTER match ip sport 23 0xffff flowid 1:10
$FILTER match ip sport 2202 0xffff flowid 1:10
$FILTER match ip sport 6121 0xffff flowid 1:10
$FILTER match ip sport 5121 0xffff flowid 1:10
$FILTER match ip sport 80 0xffff flowid 1:20
$FILTER match ip sport 443 0xffff flowid 1:20
$FILTER match ip sport 3128 0xffff flowid 1:20
$FILTER match ip src 200.189.176.206/32 flowid 1:20
$FILTER match ip src 200.189.176.205/32 flowid 1:20
$FILTER match ip sport 5065 0xffff flowid 1:20
$FILTER match ip sport 5070 0xffff flowid 1:20
$FILTER match ip sport 53 0xffff flowid 1:30
$FILTER match ip sport 25 0xffff flowid 1:30
$FILTER match ip sport 110 0xffff flowid 1:30
$FILTER match ip sport 21 0xffff flowid 1:40
On Fri, Apr 07, 2006 at 03:26:00PM -0300, Nataniel Klug wrote:> RTNETLINK answers: Invalid argument > We have an error talking to the kernelThis message usually translates to: ''tc understood your syntax just fine, and tried to tell the kernel about it, but the kernel did not understand, most likely because it does not support this feature.'' Do you have ''Netfilter marks support'' enabled? (Just a guess, may be a different setting) Regards Andreas Klauer
Andreas, This is not the problem becouse if I disable the rules I am using, and use other script just with rules using fwmark them the other script works fine. Att, Nataniel Klug Andreas Klauer escreveu:> On Fri, Apr 07, 2006 at 03:26:00PM -0300, Nataniel Klug wrote: > >> RTNETLINK answers: Invalid argument >> We have an error talking to the kernel >> > > This message usually translates to: ''tc understood your syntax just > fine, and tried to tell the kernel about it, but the kernel did not > understand, most likely because it does not support this feature.'' > > Do you have ''Netfilter marks support'' enabled? > (Just a guess, may be a different setting) > > Regards > Andreas Klauer > >
Nataniel Klug wrote:> Andreas, > > This is not the problem becouse if I disable the rules I am using, and > use other script just with rules using fwmark them the other script > works fine. > > Att, > > Nataniel Klug > > Andreas Klauer escreveu: >> On Fri, Apr 07, 2006 at 03:26:00PM -0300, Nataniel Klug wrote: >> >>> RTNETLINK answers: Invalid argument >>> We have an error talking to the kernel >>> >> >> This message usually translates to: ''tc understood your syntax just >> fine, and tried to tell the kernel about it, but the kernel did not >> understand, most likely because it does not support this feature.'' >> >> Do you have ''Netfilter marks support'' enabled? >> (Just a guess, may be a different setting) >> >> Regards >> Andreas Klauer >> >> > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > >tc filter add dev DEVICE parent M:N protocol ip prio 100 u32 match ip dst A.B.C.D/M match mark 0x0001 0xffff flowid P:Q
On 4/7/06, Nataniel Klug <nata@cnett.com.br> wrote:> Andreas, > > This is not the problem becouse if I disable the rules I am using, and > use other script just with rules using fwmark them the other script > works fine. > > Att, > > Nataniel Klug > > Andreas Klauer escreveu: > > On Fri, Apr 07, 2006 at 03:26:00PM -0300, Nataniel Klug wrote: > > > >> RTNETLINK answers: Invalid argument > >> We have an error talking to the kernel > >> > > > > This message usually translates to: ''tc understood your syntax just > > fine, and tried to tell the kernel about it, but the kernel did not > > understand, most likely because it does not support this feature.'' > > > > Do you have ''Netfilter marks support'' enabled? > > (Just a guess, may be a different setting) > > > > Regards > > Andreas Klauer > > > >When comparing your commands to mine, i noticed that you are never incrementing the prio. Possibly try your command but with prio 2. I seem to recall having issues when i was only using one prio for everything, but incrementing it with each group of filters seemed to work better. Currently i have filter rules like this: tc filter add dev $DEV parent 1:0 protocol ip prio 8 handle ${MARKP2P} fw classid 1:13 which is followed by tc filter add dev $DEV parent 1: protocol ip prio 12 u32 \ match ip tos 0x10 0xff \ flowid 1:11 If this doesn''t work, then it is likely some kernel options you need to enable, or possible you need to recompile iptables/tc? - Jody
On Fri, Apr 07, 2006 at 03:26:00PM -0300, Nataniel Klug wrote:> Hello all, >Hello> I am trying to make a filter into my QoS rules and I founded that > when I try to use filters u32 and with fwmark they do not work together. > This is the filter I use, just and example, for u32: > > $TC filter add dev $DL parent 1:0 protocol ip prio 1 u32 match ip sport > 22 0xffff flowid 1:10 > > This is working fine. Now if I try to mark a package that I want it > to go to the same class (1:10) it get an error: > > $IPT -t mangle -A PREROUTING -s 200.163.208.4 -j MARK --set-mark 10 > > Then I tryed to make the filter for this: > > $TC filter add dev $DL parent 1:0 protocol ip prio 1 handle 10 fw > classid 1:10 >In 2.4.x kernerls u32 and fwmark can''t work together , you can only mark by u32 or fwmark . In 2.6.x kernela I think from 2.6.8 or something, you can use fwmark as u32 key In menuconfig check Networking/Networking support/Networking options/ and you have "Use nfmark as a key in U32 classifier". Example : tc filter add dev eth0 protocol ip parent 1:0 prio 5 u32 \ match mark 0x0090 0xffff \ match ip dst 4.4.4.4 \ flowid 1:90 /pch -- Dyslexia bug unpatched since 1977 ... exploit has been leaked to the underground.
Jody, I think it worked fine... This is my new script (below the text). I just dont know how can I know if this traffic is relly going to the class I send it... hehehehe... I am marking Skype packages using L7-Filter like this: $IPT -t mangle -A PREROUTING -m layer7 --l7proto skypetoskype -j MARK --set-mark 10 Att, Nataniel Klug -------------------------------- #!/bin/sh #------ # Script de QoS Cyber Nett #------ # Nataniel Klug # suporte@cnett.com.br #------ TC="/sbin/tc" IPT="/usr/local/sbin/iptables" DL="eth3" #------ # Apagando regras antigas de QoS #------ $TC qdisc del dev $DL root 2> /dev/null > /dev/null $TC qdisc del dev $DL ingress 2> /dev/null > /dev/null #------ # Regras para a placa eth1 #------ $TC qdisc add dev $DL root handle 1: htb default 50 CLASS="/sbin/tc class add dev $DL parent" $CLASS 1: classid 1:1 htb rate 3072Kbit $CLASS 1:1 classid 1:10 htb rate 384Kbit prio 1 $CLASS 1:1 classid 1:20 htb rate 1024Kbit ceil 2048Kbit prio 2 $CLASS 1:1 classid 1:30 htb rate 512Kbit ceil 512Kbit prio 3 $CLASS 1:1 classid 1:40 htb rate 512Kbit ceil 512Kbit prio 4 $CLASS 1:1 classid 1:50 htb rate 640Kbit ceil 640Kbit prio 5 QDISC="/sbin/tc qdisc add dev $DL parent" $QDISC 1:10 handle 10: sfq perturb 10 $QDISC 1:20 handle 20: sfq perturb 10 $QDISC 1:30 handle 30: sfq perturb 10 $QDISC 1:40 handle 40: sfq perturb 10 $QDISC 1:50 handle 50: sfq perturb 10 FILTER="/sbin/tc filter add dev $DL parent 1:0 protocol" $FILTER ip prio 11 u32 match ip protocol 1 0xff flowid 1:10 $FILTER ip prio 12 u32 match ip sport 22 0xffff flowid 1:10 $FILTER ip prio 12 u32 match ip sport 23 0xffff flowid 1:10 $FILTER ip prio 12 u32 match ip sport 2202 0xffff flowid 1:10 $FILTER ip prio 13 u32 match ip sport 6121 0xffff flowid 1:10 $FILTER ip prio 13 u32 match ip sport 5121 0xffff flowid 1:10 $FILTER ip prio 14 handle 10 fw classid 1:10 $FILTER ip prio 21 u32 match ip sport 80 0xffff flowid 1:20 $FILTER ip prio 21 u32 match ip sport 443 0xffff flowid 1:20 $FILTER ip prio 21 u32 match ip sport 3128 0xffff flowid 1:20 $FILTER ip prio 22 u32 match ip src 200.189.176.206/32 flowid 1:20 $FILTER ip prio 22 u32 match ip src 200.189.176.205/32 flowid 1:20 $FILTER ip prio 22 u32 match ip sport 5065 0xffff flowid 1:20 $FILTER ip prio 22 u32 match ip sport 5070 0xffff flowid 1:20 $FILTER ip prio 31 u32 match ip sport 53 0xffff flowid 1:30 $FILTER ip prio 32 u32 match ip sport 25 0xffff flowid 1:30 $FILTER ip prio 32 u32 match ip sport 110 0xffff flowid 1:30 $FILTER ip prio 41 u32 match ip sport 21 0xffff flowid 1:40
On Sat, Apr 08, 2006 at 08:21:40AM -0300, Nataniel Klug wrote:> I think it worked fine... This is my new script (below the text). I just > dont know how can I know if this traffic is relly going to the class I > send it... hehehehe... I am marking Skype packages using L7-Filter like > this: >If you want to see packets in class you can use sch_log, quite good module, you must attach it to class and you will see every packet in this class in tcpdump. http://kernel.umbrella.ro/net/sch_log/v0.4/sch_log-0.4.tar.gz or Vincent Perrier''s sch_spy (I don''t have url). /pch -- Dyslexia bug unpatched since 1977 ... exploit has been leaked to the underground.
On Sat, Apr 08, 2006 at 03:18:01PM +0200, Piotr Chytla wrote:> On Sat, Apr 08, 2006 at 08:21:40AM -0300, Nataniel Klug wrote: > > I think it worked fine... This is my new script (below the text). I just > > dont know how can I know if this traffic is relly going to the class I > > send it... hehehehe... I am marking Skype packages using L7-Filter like > > this: > > > If you want to see packets in class you can use sch_log, quite good > module, you must attach it to class and you will see every packet > in this class in tcpdump.Or, without additional software, and a bit less of information, you could just have a look at the tc statistics. In case of mixed classes you can temporarily create an extra class for the packets you want to test filters on. If packets go into this class and it''s the same number as are marked by iptables, the classification works. Regards Andreas Klauer
Thank you all for the answers... Andreas Klauer escreveu:> On Sat, Apr 08, 2006 at 03:18:01PM +0200, Piotr Chytla wrote: > >> On Sat, Apr 08, 2006 at 08:21:40AM -0300, Nataniel Klug wrote: >> >>> I think it worked fine... This is my new script (below the text). I just >>> dont know how can I know if this traffic is relly going to the class I >>> send it... hehehehe... I am marking Skype packages using L7-Filter like >>> this: >>> >>> >> If you want to see packets in class you can use sch_log, quite good >> module, you must attach it to class and you will see every packet >> in this class in tcpdump. >> > > Or, without additional software, and a bit less of information, > you could just have a look at the tc statistics. In case of mixed > classes you can temporarily create an extra class for the packets > you want to test filters on. > > If packets go into this class and it''s the same number as are marked > by iptables, the classification works. > > Regards > Andreas Klauer > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > >