similar to: tc filter: match tcp src vs. match ip sport

Hi all :)) Sorry for asking again, but got no answers and google doesn''t give useful information (seems like "nexthdr" doesn''t work right, but I don''t know why...). I really want to know what am I doing wrong... This filter matches what I want: tc filter add dev eth0 protocol ip parent 1:0 prio 9 u32\ match ip sport 0x3000 0xf000

Hi all :) If I set the burst/cburst parameter to, let''s say, 1500, the command "tc -s -d class show dev eth0" says that the value is 1499b/8 instead of the (correct?) 1500b/8. Is this right or am I doing anything wrong? Many thanks in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net

Hi all :) Currently I''m shaping the traffic that goes to my ADSL router, using HTB. . Root (HTB) 1: . | . |------------------------| . LAN (1:1) ADSL router (1:2) . 90Mbit/90MBit 200000bit/200000bit . | . (Here go some children classes) I find the above a bit overkill, since LAN and

Hi all :) I''m new to this list, as I''m new too to traffic shaping ;) I''ve set up an FTP server in my ADSL line and I wanted it to serve as fast as possible as long as I don''t use my outgoing ADSL bandwidth, and I''m currently using HTB for that (succesfully, I must add). The problem is (when the FTP server is serving higher than its

Hi all :) I think that this issue has already been discussed on this list, but google didn''t find anything interesting, so I''m bringing the subject again. The output of "tc" uses "b" meaning "byte" and "bit" for "bit". The "official" suffixes for those units are "B" and "b", respectively,

Hi all :) I''ve been using a tc setup for almost two years, but at some point (probably when I switched to kernel 2.6.x, but I''m not sure) it has started making something very weird. For a certain class, the rate is 125000bit and the ceil is 270000bit, but the fastest rate I get is about 75-80000bit, instead of the "promised" 125000, *with no other traffic in

I visited yesican.chsoft.biz and the author proposes a way to match packets by less than some size . Here is the thing: match u16 0x0000 0xffb0 at 2 With this match he says that packet with less than 80 bytes will match the rule. Well, 0xffb0 translates to 1111 1111 1011 0000 (which is -80 BTW). So, if I am correct any packet with bits 4 and/or 5 set (together with any of the 4

Hi all :) I''ve tested this and having a cpufreq that slows down the CPU affects the rate of HTB. My ondemand cpufreq governor scales down the CPU frequency about 40% and this is more or less the slowdown the rate suffers, 40%. Any known way of dealing with this without having to disable cpufreq? Thanks in advance :) Ra?l N??ez de Arenas Coronado -- Linux Registered

Hi All How to classify packets belonging to a FTP session? Port 21 session is easy. but what about data transfers? Their port numbers (both) are above 1024. I was thinking about ip_conntrack_ftp. Something like: iptables -A FORWARD -p tcp --sport 1024: --dport 1024: \ -m state --state ESTABLISHED,RELATED -j CLASSIFY --set-class X:Y But what if I also have ip_conntrack_irc, for instance.

Hello all, I got this problem while trying to shape traffic with iptables MARK and HTB. MARK: targinfosize 8 != 4 --set-mark gives "invalid argument" error message. Kernel version is 2.4.29 (some patches from patch o matic applied) Iptables version 1.3.4 Intel x86 architecture. I saw this problem discussed in a few places, but the discussions didn''t come to a conclusion

I have found a few bugs in tc, and have produced patches for them. Two require changes to tc, one to the kernel. Where should I post these patches? -- Regards, Russell Stuart

Hi, all: I''m involved in the study about the QoS,but have some problems , hope someone could help me answer: 1. Why most traffic shaping implement in the egress side (Uplink) rather than the ingress side(Dnlink)?(e.g. why put the police rule on the smaller bandwidth side but not put on the larger side) 2. I can''t differ the functionalities exactly

I want to stop shaping from running on my box, without rebooting it. What''s the best way to get rid of any tc rules? I have tried "tc qdisc del dev eth0 root" which appeared to be successful but traffic through my box is still very slow. Cheers, Jonathan ------------------------ Jonathan Gazeley ResNet | Wireless & VPN Team Information Systems & Computing University

After carefull reading (LARTC) and experimentation, I am in a dead end... I am using several IPIP tunnels (linux ipip module, IP protocol 4). I''d like to filter packets going through these tunnes to different classes, on the ingress device, based on source and destination IP _INSIDE THE TUNNEL_. First I tried the nexthdr bit. As explained in LARTC, nexthdr jumps to the next header

Hi. Is there anyone who has understood of how u32 nexthdr addressing is supposed to work? (including the "tcp/icmp/.." matches who implicitly uses nexthdr) From reading the kernel code it apparently is using the location set by "offset at", but this seems to only be evaluated on hash parents, and only for it''s children.. I.e. the logic for u32 filter rule

Porque con "less" estás hacienddo un test de una cola. En tu ejemplo estás haciendo un test de dos colas: > 2*pt(-5.4349,df=21.982) [1] 1.855473e-05 El 21/12/2013 21:33, HERNANDEZ CORONADO JORGE escribió: > t.test(1:10,y=c(7:20)) > > Welch Two Sample t-test > > data: 1:10 and c(7:20) > t = -5.4349, df = 21.982, p-value = 1.855e-05 > alternative hypothesis:

Si miras el código de t.test() verás que para calcular el p-valor llama a pt(). En la página de ayuda de pt() se cuenta que: "For the central case of pt, a normal approximation in the tails, otherwise via pbeta. For the non-central case of pt based on a C translation of Lenth, R. V. (1989). Algorithm AS 243 ? Cumulative distribution function of the non-central t distribution, Applied

https://bugzilla.netfilter.org/show_bug.cgi?id=946 Summary: Cannot invert a protocol: ip protocol != tcp Product: nftables Version: unspecified Platform: x86_64 OS/Version: Debian GNU/Linux Status: NEW Severity: enhancement Priority: P5 Component: nft AssignedTo: pablo at netfilter.org

I''m having trouble with nexthdr. tc filter add dev eth0 protocol ip parent 10:0 prio 1 u32 \ match ip protocol 0x6 0xff match u8 0x02 0x12 at nexthdr+13 flowid 10:3 fails to match my test packets whereas tc filter add dev eth0 protocol ip parent 10:0 prio 1 u32 \ match ip protocol 0x6 0xff match u8 0x02 0x12 at 33 flowid 10:3 does match them. Of course, the second one is really wrong

I still think that nexthdr should be fixed, but I''d like to mention that iptables --protocol tcp can do pretty much the same thing. That is, tc filter add dev $1 protocol ip parent 10:0 prio 1 u32 \ match ip protocol 0x6 0xff match u8 0x02 0x16 at nexthdr+13 flowid 10:3 can be replaced by iptables -A PREROUTING -t mangle -p tcp --syn -j MARK --set-mark 2 tc filter add dev $1 protocol