RE: [LARTC] HTB - prio and rate
Jody - Many thanks for taking the time to reply. It's greatly helped my understanding. From: Jody Shumaker [mailto:[EMAIL PROTECTED] Sent: 12 December 2005 19:14To: Mark LidstoneSubject: Re: [LARTC] HTB - prio and rate No, I wrote what I meant. If classes 1:11 and 1:12 are contending for bandwidth the prio values will have no effect as they are the same. I was making the point that they would get equal shares of the spare bandwidth because they have equal rates (the sparebandwidth is shared out with classes that have higher rates getting moreof the bandwidth than classes with lower rates). Ahh, now that I read it again it does read that way. Sorry about misreading it. OK, so the_ratio_ of rate values for child classes is only taken into account when sharing bandwidth with other child classes that have the same prio value? That has been my experience. However, in practice things won't always confirm to these rules exactly. I think that is more of caused by how TCP throttles bandwidth. In general though the priority does have the intended effect. - Jody ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] MARK: targinfosize 8 != 4
Hi Salim :) * Salim [EMAIL PROTECTED] dixit: 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 or solution. You've hit a bug in iptables :( I've notified in the bugzilla but I have had no answers. You're building iptables with no shared libraries (NO_SHARED_LIBS=1). This means that the code in iptables, when loading the modules for the matches and targets is taking a slightly different code path. The problem is that the MARK target has two versions, 0 and 1, and kernel 2.4.x (at least until 31) supports only version 0. If you don't use share libraries in iptables, both versions are loaded and v1 is used instead of v2. Unfortunately, v1 has a bigger data structure than v0 and your kernel complaints. The only solution for your problem is to rebuild iptables with shared libraries instead of compiling the matches and targets in the binary, statically. I've tried to make a patch, and worked for me but I don't want to mess anything so I've described the problem, the wrong code path and other details to the iptables people. If you want to take a look the bug is #413 in bugzilla.netfilter.org And yes, nobody seems to have this problem because it seems that only few people uses iptables built statically :?? or because nobody seems to be interested. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Marking packets by mac addr using tc filter u32 match?
Hi, Forgive me if I point out the obvious. Remember that ARP isn't an IP protocol it's a peer protocol to IP. In the tc filters shown below the protocol is IP and the negative offset works on a IP packet but I suspect that an ARP packet isn't accessible with this technique. If I ubstitute IP for ARP in the filter statement it isn't accepted. Regards Mike D. Kristiadi Himawan wrote: it's should be 0x0806 0x ? or you have the example how to catch that kind of traffic gypsy wrote: Kristiadi Himawan wrote: It's also match to this kind of traffic ? 17:16:53.740978 arp who-has 192.43.165.29 tell 192.43.165.30 17:16:53.752482 arp reply 192.43.165.29 is-at 00:04:c1:b5:bd:f1 17:16:53.812889 arp who-has 192.43.162.194 tell 192.43.162.193 17:16:53.812922 arp reply 192.43.162.194 is-at 00:08:c7:c9:a3:17 No. The 'match u16 0x0800 0x' says to ignore ARP. Lee Sanders wrote: You haven't done a search on past posts... the u32 can be used to match any bit in the ip header. Before the ip header, there is a frame header. In that frame header you can find the src and dst mac address. You can trick the u32 filter in using the frame header if you use negative offsets. Decimal Offset Description -14:DST MAC, 6 bytes -8: SRC MAC, 6 bytes -2: Eth PROTO, 2 bytes, eg. ETH_P_IP 0: Protocol header (IP Header) Where is the Eth Proto Code (from linux/include/linux/if_ether.h): ETH_P_IP= IP = match u16 0x0800 Where your MAC = M0M1M2M3M4M5 Egress (match Dst MAC): ... match u16 0x 0x at -2 match u32 0xM2M3M4M5 0x at -12 match u16 0xM0M1 0x at -14 Ingress (match Src MAC): ... match u16 0x 0x at -2 match u16 0xM4M5 0x at -4 match u32 0xM0M1M2M3 0x at -8 The below is simplistic but it works to demonstrate the above. tc qdisc add dev ppp0 root handle 1:0 htb default 20 tc class add dev ppp0 parent 1:0 classid 1:1 htb rate 128kbit ceil 128kbit tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 64kbit ceil 128kbit tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 64kbit ceil 128kbit tc qdisc add dev ppp0 parent 1:10 handle 100: sfq perturb 10 tc qdisc add dev ppp0 parent 1:20 handle 200: sfq perturb 10 # My Laptop tc filter add dev ppp0 parent 1:0 protocol ip prio 1 u32 match u16 0x0800 0x at -2 match u16 0xM4M5 0x at -4 match u32 0xM0M1M2M3 0x at -8 flowid 1:10 # My Desktop tc filter add dev ppp0 parent 1:0 protocol ip prio 1 u32 match u16 0x0800 0x at -2 match u16 0xM4M5 0x at -4 match u32 0xM0M1M2M3 0x at -8 flowid 1:20 # change the MAC's of course. tc -s -d class show dev ppp0 tc -s -d qdisc show dev ppp0 tc -s -d filter show dev ppp0 There you have it. :L ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Regards Mike. Michael Davidson Barone Budge Dominick Email: [EMAIL PROTECTED] Office: +27 11 532 8380 BBD : +27 11 532 8300 Fax:+27 11 532 8400 Mobile: +27 82 650 5707 Home: +27 11 452 4423 This e-mail is confidential and subject to the disclaimer published at http://www.bbd.co.za ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Marking packets by mac addr using tc filter u32 match?
So is there a technique to filter this kind of ARP traffic ? 17:16:53.740978 arp who-has 192.43.165.29 tell 192.43.165.30 17:16:53.752482 arp reply 192.43.165.29 is-at 00:04:c1:b5:bd:f1 17:16:53.812889 arp who-has 192.43.162.194 tell 192.43.162.193 17:16:53.812922 arp reply 192.43.162.194 is-at 00:08:c7:c9:a3:17 Anyone can help? Michael Davidson wrote: Hi, Forgive me if I point out the obvious. Remember that ARP isn't an IP protocol it's a peer protocol to IP. In the tc filters shown below the protocol is IP and the negative offset works on a IP packet but I suspect that an ARP packet isn't accessible with this technique. If I ubstitute IP for ARP in the filter statement it isn't accepted. Regards Mike D. Kristiadi Himawan wrote: it's should be 0x0806 0x ? or you have the example how to catch that kind of traffic gypsy wrote: Kristiadi Himawan wrote: It's also match to this kind of traffic ? 17:16:53.740978 arp who-has 192.43.165.29 tell 192.43.165.30 17:16:53.752482 arp reply 192.43.165.29 is-at 00:04:c1:b5:bd:f1 17:16:53.812889 arp who-has 192.43.162.194 tell 192.43.162.193 17:16:53.812922 arp reply 192.43.162.194 is-at 00:08:c7:c9:a3:17 No. The 'match u16 0x0800 0x' says to ignore ARP. Lee Sanders wrote: You haven't done a search on past posts... the u32 can be used to match any bit in the ip header. Before the ip header, there is a frame header. In that frame header you can find the src and dst mac address. You can trick the u32 filter in using the frame header if you use negative offsets. Decimal Offset Description -14:DST MAC, 6 bytes -8: SRC MAC, 6 bytes -2: Eth PROTO, 2 bytes, eg. ETH_P_IP 0: Protocol header (IP Header) Where is the Eth Proto Code (from linux/include/linux/if_ether.h): ETH_P_IP= IP = match u16 0x0800 Where your MAC = M0M1M2M3M4M5 Egress (match Dst MAC): ... match u16 0x 0x at -2 match u32 0xM2M3M4M5 0x at -12 match u16 0xM0M1 0x at -14 Ingress (match Src MAC): ... match u16 0x 0x at -2 match u16 0xM4M5 0x at -4 match u32 0xM0M1M2M3 0x at -8 The below is simplistic but it works to demonstrate the above. tc qdisc add dev ppp0 root handle 1:0 htb default 20 tc class add dev ppp0 parent 1:0 classid 1:1 htb rate 128kbit ceil 128kbit tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 64kbit ceil 128kbit tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 64kbit ceil 128kbit tc qdisc add dev ppp0 parent 1:10 handle 100: sfq perturb 10 tc qdisc add dev ppp0 parent 1:20 handle 200: sfq perturb 10 # My Laptop tc filter add dev ppp0 parent 1:0 protocol ip prio 1 u32 match u16 0x0800 0x at -2 match u16 0xM4M5 0x at -4 match u32 0xM0M1M2M3 0x at -8 flowid 1:10 # My Desktop tc filter add dev ppp0 parent 1:0 protocol ip prio 1 u32 match u16 0x0800 0x at -2 match u16 0xM4M5 0x at -4 match u32 0xM0M1M2M3 0x at -8 flowid 1:20 # change the MAC's of course. tc -s -d class show dev ppp0 tc -s -d qdisc show dev ppp0 tc -s -d filter show dev ppp0 There you have it. :L ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] MARK: targinfosize 8 != 4
DervishD wrote: Hi Salim :) * Salim [EMAIL PROTECTED] dixit: 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 or solution. You've hit a bug in iptables :( I've notified in the bugzilla but I have had no answers. You're building iptables with no shared libraries (NO_SHARED_LIBS=1). This means that the code in iptables, when loading the modules for the matches and targets is taking a slightly different code path. The problem is that the MARK target has two versions, 0 and 1, and kernel 2.4.x (at least until 31) supports only version 0. If you don't use share libraries in iptables, both versions are loaded and v1 is used instead of v2. Unfortunately, v1 has a bigger data structure than v0 and your kernel complaints. That can't be the reason, all revisions of a single match/target are in the same object file and the supported revision is (supposed to be) probed. Salim, can you send a strace of the failing iptables command? ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Some questions
First of all, thank you to all of you who have helped to make iptables possible, whether in writing the code for it or testing it. It is BETTER than sliced bread! :-) Anyways, I have two questions related to the use of iptables. 1. I read on a post somewhere that it is smart to put the following two rules at the end of one's iptables ruleset: iptables -A INPUT -p tcp -i eth0 -j REJECT --reject-with tcp-reset iptables -A INPUT -p udp -i eth0 -j REJECT --reject-with tcp-reset The reasoning was that it would not look like a software firewall, but rather would look like a machine that had no open ports. Does this sound reasonable? What would all of you do? 2. I also read on some website that it is important to use this line in the setup for iptables: echo 1 /proc/sys/net/ipv4/conf/eth0/rp_filter What does this do (it said something about spoofing, but I did not understand), and is it necessary? Thank you all for your enlightenment! Robb ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Marking packets by mac addr using tc filter u32 match?
Kristiadi Himawan wrote: So is there a technique to filter this kind of ARP traffic ? 17:16:53.740978 arp who-has 192.43.165.29 tell 192.43.165.30 17:16:53.752482 arp reply 192.43.165.29 is-at 00:04:c1:b5:bd:f1 17:16:53.812889 arp who-has 192.43.162.194 tell 192.43.162.193 17:16:53.812922 arp reply 192.43.162.194 is-at 00:08:c7:c9:a3:17 Anyone can help? This works for me: http://duron/lartc/arp.html # Example that matches ARP (a big thank you to Martin Brown for this!): # the ARP protocol is 2 bytes at -2 # the 0806 comes from linux/include/linux/if_ether.h tc filter add dev $DEV parent 1: protocol ip prio 5 u32 \ match u16 0x0806 0x at -2 flowid 1:50 -- gypsy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Some questions
On Dec 13, 2005, at 7:43 AM, Robb Bossley wrote: Anyways, I have two questions related to the use of iptables. 1. I read on a post somewhere that it is smart to put the following two rules at the end of one's iptables ruleset: iptables -A INPUT -p tcp -i eth0 -j REJECT --reject-with tcp-reset iptables -A INPUT -p udp -i eth0 -j REJECT --reject-with tcp-reset The reasoning was that it would not look like a software firewall, but rather would look like a machine that had no open ports. Does this sound reasonable? What would all of you do? I only have one comment about that reject udp packets with a tcp reset? I think that would look more like a very inventive implementation of tcp/udp over ip ;) OK, second comment: it really depends on what you want your box to appear as. 2. I also read on some website that it is important to use this line in the setup for iptables: echo 1 /proc/sys/net/ipv4/conf/eth0/rp_filter What does this do (it said something about spoofing, but I did not understand), and is it necessary? It ensures that you don't generate martian packets. If your ip is 10.0.0.1, your interface will only spit out packets with that ip address, and silently drop the rest. -Jeff SIG: HUP ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] MARK: targinfosize 8 != 4
Hi Jones :))) * Jones Desougi [EMAIL PROTECTED] dixit: That can't be the reason, all revisions of a single match/target are in the same object file and the supported revision is (supposed to be) probed. They are not due to the DONT_LOAD usage ;)) The patch below is much better than the one I tested ;))) Try the patch below. (It's bug #413 in bugzilla) Thanks a lot :)) I'll test it as soon as I can. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Some questions
Robb Bossley wrote: echo 1 /proc/sys/net/ipv4/conf/eth0/rp_filter What does this do (it said something about spoofing, but I did not understand), and is it necessary? http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html#AEN634 Georgi Alexandrov ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] MARK: targinfosize 8 != 4
Jones Desougi wrote: That can't be the reason, all revisions of a single match/target are in the same object file and the supported revision is (supposed to be) probed. Salim, can you send a strace of the failing iptables command? The key being supposed to be. :-) I somehow expected something like this :) Try the patch below. (It's bug #413 in bugzilla) This looks good, thanks. I'm going to apply it as soon as there is confirmation that it really fixes the problem people are seeing. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] MARK: targinfosize 8 != 4
It worked when I changed to NO_SHARED_LIBS=0. thanks guys. will try out the patch today. the command that was failing was a simple --set-mark. Let me know if anyone still wants an strace. Will send it. - Original Message - From: Patrick McHardy [EMAIL PROTECTED] To: DervishD [EMAIL PROTECTED] Cc: Salim [EMAIL PROTECTED]; lartc@mailman.ds9a.nl; Netfilter Development Mailinglist [EMAIL PROTECTED] Sent: Tuesday, December 13, 2005 8:01 PM Subject: Re: [LARTC] MARK: targinfosize 8 != 4 DervishD wrote: Hi Salim :) * Salim [EMAIL PROTECTED] dixit: 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 or solution. You've hit a bug in iptables :( I've notified in the bugzilla but I have had no answers. You're building iptables with no shared libraries (NO_SHARED_LIBS=1). This means that the code in iptables, when loading the modules for the matches and targets is taking a slightly different code path. The problem is that the MARK target has two versions, 0 and 1, and kernel 2.4.x (at least until 31) supports only version 0. If you don't use share libraries in iptables, both versions are loaded and v1 is used instead of v2. Unfortunately, v1 has a bigger data structure than v0 and your kernel complaints. That can't be the reason, all revisions of a single match/target are in the same object file and the supported revision is (supposed to be) probed. Salim, can you send a strace of the failing iptables command? ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Some questions
Robb Bossley wrote: echo 1 /proc/sys/net/ipv4/conf/eth0/rp_filter What does this do (it said something about spoofing, but I did not understand), and is it necessary? http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html#AEN634 Georgi Alexandrov ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
