u32 filter won't match

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

I really need help with a u32 filter that won't match what I think I'm
telling it to. The situation is that I have set up an internal
computer to change the TOS value of packets sent by certain processes
to 0x1E (If anyone known of a better way to mark packets, please tell
me. I would love to find some module that adds an IP option with UIDs
and GIDs to the packets - does anyone know if such a module already
exists?), and I want my router to deprioritize them. I also want to
limit my outbound bandwidth to 750kbit overall. So anyway, this is my
qdisc setup:

tc qdisc add dev eth1 root handle 1: cbq bandwidth 10mbit \
    avpkt 1000 rate 750kbit cell 8
tc qdisc add dev eth1 parent 1: handle 2: prio bands 4
tc qdisc add dev eth1 parent 2:1 handle 3: sfq perturb 10
tc qdisc add dev eth1 parent 2:2 handle 4: sfq perturb 10
tc qdisc add dev eth1 parent 2:3 handle 5: sfq perturb 10
tc qdisc add dev eth1 parent 2:4 handle 6: sfq perturb 5

So far so good. All packets go to the right qdisc among 3: - 5: (As
seen with "tc -s qdisc ls"). However, when I add the filter to make
packets with TOS 0x1E go to 6:, I set it up like this:

tc filter add dev eth1 parent 1: protocol ip prio 1 \
    u32 match ip tos 0x1e 0xff flowid 6:

I am under the impression that it should be done like that. However,
that filter simply doesn't match the packets. I have tried some
combinations, like setting the flowid to 2:4 instead or using parent
2:. (The strange thing is that when I used "parent 2:", no filter was
added at all... What's up with that?) Also, in case you're wondering,
I have checked so that the packets actually are marked with TOS=0x1E,
and they are.

I'm sure I have just missed something and am wasting your time, but
please, I just can't see what I'm missing...

Oh, and by the way, it would be nice to unmark the packets again
before they go out, and setting up an iptables rule for that is, of
course, very simple. However, since that happens before the packets
are enqueued, that removes the mark before the filters are classified,
which isn't really my intention... Is there any other way of demarking
the packets that doesn't interfere with the QoS setup?

Thank you very much for your time!

Fredrik Tolf

_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux