Re: [LARTC] tc: u32 match in nexthdr not working?

Linux Advanced Routing and Traffic Control

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

 



On Thu, Dec 13, 2001 at 08:46:57PM +0100, Lutz Pressler wrote:

> The following has no effect on 2.4.16 or older (even 2.2) kernels:
> 
> # tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match tcp
> dst 3128 0xffff police rate 40kbit burst 10k drop flowid :1

Double check what this means! This limits speed of data *coming in to* your
proxy from a client (browser). That is not a lot - most data will flow he
other way, and will indeed not be matched.

Data being received BY your proxy from the internet is not matched by this
proxy.

> Even if
> # tc filter ls dev eth0 parent ffff:
> filter protocol ip pref 50 u32
> filter protocol ip pref 50 u32 fh 800: ht divisor 1

> filter protocol ip pref 50 u32 fh 800::800 order 2048 key ht 800 bkt 0
> flowid :1 police 4 action drop rate 40Kbit burst 10Kb mtu 2Kb
>   match 00000c38/0000ffff at nexthdr+0

You supply a lot of redundant information. I'm not sure what the '4' means
in this rule.

> looks reasonable, TCP connections to port 3128 are not policed.
> 
> If I use "match ip dst <ip-address>" instead, the policing works.

Your proxy does no necessarily download FROM port 3128! 

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
Trilab                                 The Technology People
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet



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