RE: [LARTC] HTB and bittorrent, won't work
You can classify kopete traffic using iptables rules. Depending on the im protocol you use. Yahoo messenger uses TCP ports 5050 and 5051 i think.. MSN uses TCP 1863... you can google for them. You also have to setup tcp_sport as the squid port in orded for the l7 http filter to work. And if that is not working classify using iptables as source your internal eth ip and source port your squid port. There is a slighter chance that some btclients will use the same ports as described in the iptables rules... but i don't think that will mess up your shaping that bad. Iosif Peterfi S.C. Forte Systems SRL http://www.fortesys.ro/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Edgar Sent: Thursday, July 07, 2005 11:35 PM To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] HTB and bittorrent, won't work Thank you for your response, I will try to do what you told me, but I have a squid sever, and I don't know which port I should use for that, since the http layer7 protocol won't work, when I have that mark rule in iptables I don't see traffic going into that rule, it'll only work when I'm surfing the web without the squid cache; another problem I have is that the msn messenger I use (kopete for kde) isn't recognized by the layer7 protocol, so the question is this, can I do this specifying the ports in tcng ? EDGAR MERINO On Thursday 07 July 2005 06:36, Forte Systems - Iosif Peterfi wrote: > I would suggest classifing interactive connections, and leave all the bulk > traffic in the default class. This way, the bt,kazaa,emule traffic will go > in the same class, without additional filtering. > Also, using HFSC instead of HTB helps you increase the delay of the default > class. This way bulk traffic will be sent every n ms, leaving priority to > the interactive/web/mail traffic. Think about it. > > > Iosif Peterfi > S.C. Forte Systems SRL > http://www.fortesys.ro/ > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Klaus > Sent: Thursday, July 07, 2005 10:22 AM > To: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] HTB and bittorrent, won't work > > ipp2p vs. l7 filter > > l7 uses regular expressions, so they are slower (some rules are EXTREME > slow like fasttrack) and not so strong like the ipp2p rules (which can > have for example packet length checks). ipp2p is specialized for p2p > detection, so a many p2p packets are not detected by l7 (for example not > all BitTorrent connections start with a 013h "BitTorrent"). The worst > part is that l7 filter has some p2p rules which detect false positives: > > http://l7-filter.sourceforge.net/layer7-protocols/protocols/edonkey.pat > > "... This will match about 1% of streams with random data in them! ..." > > If you drop p2p connection, one of hundred downloads / web pages will > fail (and fail every time) ? > > I would recommend l7-filter for everything but not for p2p. It is a VERY > nice filter, but if they would have something else than regexp, i would > use it maybe too. > > Klaus, Maintainer of ipp2p > > Edgar wrote: > > Hi, thanks for your help and interest, someone told me about that > > already, > > so > > > I did it, and this is the script I'm running to do it: > > #!/bin/sh > > > > ### ERASING RULES AND USER CREATED CHAINS ### > > iptables -t mangle -F > > iptables -t mangle -X > > iptables -t mangle -N lay7PRE > > iptables -t mangle -N lay7POST > > > > ### PREROUTING RULES ### > > iptables -t mangle -A lay7PRE -j CONNMARK --restore-mark > > iptables -t mangle -A lay7PRE -m mark ! --mark 0 -j ACCEPT > > iptables -t mangle -A lay7PRE -m layer7 --l7proto bittorrent -j MARK > > --set-mark 1 > > iptables -t mangle -A lay7PRE -m layer7 --l7proto smtp -j MARK --set-mark > > 2 > > > iptables -t mangle -A lay7PRE -m layer7 --l7proto http -j MARK --set-mark > > 3 > > > iptables -t mangle -A lay7PRE -j CONNMARK --save-mark > > > > ### POSTROUTING RULES ### > > iptables -t mangle -A lay7POST -o eth1 -m mark --mark 1 -j CLASSIFY > > --set-class 2:2 > > iptables -t mangle -A lay7POST -o eth1 -m mark --mark 2 -j CLASSIFY > > --set-class 2:3 > > iptables -t mangle -A lay7POST -o eth1 -m mark --mark 3 -j CLASSIFY > > --set-class 2:4 > > > > ### --- > > ### > > > iptables -t mangle -A PREROUTING -j lay7PRE > > iptables -t mangle -A POSTROUTING -j lay7POST > > > > I'm trying this right now, and I believe its kind of working, but web > > surfing > > > is very slow, I might say unusab
RE: [LARTC] HTB and bittorrent, won't work
I would suggest classifing interactive connections, and leave all the bulk traffic in the default class. This way, the bt,kazaa,emule traffic will go in the same class, without additional filtering. Also, using HFSC instead of HTB helps you increase the delay of the default class. This way bulk traffic will be sent every n ms, leaving priority to the interactive/web/mail traffic. Think about it. Iosif Peterfi S.C. Forte Systems SRL http://www.fortesys.ro/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Klaus Sent: Thursday, July 07, 2005 10:22 AM To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] HTB and bittorrent, won't work ipp2p vs. l7 filter l7 uses regular expressions, so they are slower (some rules are EXTREME slow like fasttrack) and not so strong like the ipp2p rules (which can have for example packet length checks). ipp2p is specialized for p2p detection, so a many p2p packets are not detected by l7 (for example not all BitTorrent connections start with a 013h "BitTorrent"). The worst part is that l7 filter has some p2p rules which detect false positives: http://l7-filter.sourceforge.net/layer7-protocols/protocols/edonkey.pat "... This will match about 1% of streams with random data in them! ..." If you drop p2p connection, one of hundred downloads / web pages will fail (and fail every time) ? I would recommend l7-filter for everything but not for p2p. It is a VERY nice filter, but if they would have something else than regexp, i would use it maybe too. Klaus, Maintainer of ipp2p Edgar wrote: > Hi, thanks for your help and interest, someone told me about that already, so > I did it, and this is the script I'm running to do it: > #!/bin/sh > > ### ERASING RULES AND USER CREATED CHAINS ### > iptables -t mangle -F > iptables -t mangle -X > iptables -t mangle -N lay7PRE > iptables -t mangle -N lay7POST > > ### PREROUTING RULES ### > iptables -t mangle -A lay7PRE -j CONNMARK --restore-mark > iptables -t mangle -A lay7PRE -m mark ! --mark 0 -j ACCEPT > iptables -t mangle -A lay7PRE -m layer7 --l7proto bittorrent -j MARK > --set-mark 1 > iptables -t mangle -A lay7PRE -m layer7 --l7proto smtp -j MARK --set-mark 2 > iptables -t mangle -A lay7PRE -m layer7 --l7proto http -j MARK --set-mark 3 > iptables -t mangle -A lay7PRE -j CONNMARK --save-mark > > ### POSTROUTING RULES ### > iptables -t mangle -A lay7POST -o eth1 -m mark --mark 1 -j CLASSIFY > --set-class 2:2 > iptables -t mangle -A lay7POST -o eth1 -m mark --mark 2 -j CLASSIFY > --set-class 2:3 > iptables -t mangle -A lay7POST -o eth1 -m mark --mark 3 -j CLASSIFY > --set-class 2:4 > > ### --- ### > iptables -t mangle -A PREROUTING -j lay7PRE > iptables -t mangle -A POSTROUTING -j lay7POST > > I'm trying this right now, and I believe its kind of working, but web surfing > is very slow, I might say unusable, so this is not what I want, also I had to > mark http traffic to make this work, give it a higher prio in htb, so I > believe I'm missing something else? someone suggested to add a new class for > ACK packets, I've done that already, but I've only noticed little > difference... really don't know whats happening, if you don't have tcng I can > show you my tc rules (showed by tc -s class show dev eth1). Thank you again > > EDGAR MERINO > > On Wednesday 06 July 2005 23:30, Jody Shumaker wrote: > >>You need to use connection marking as well. --l7proto bittorrent will >>only recognize the first packet in a bittorrent stream, you need to save >>a mark on the whole tcp connection, and restore the mark for all future >>packets if you want the entire connection to be classified. >> >>iptables -t mangle -A lay7 -p tcp -j CONNMARK --restore-mark >>iptables -t mangle -A lay7 -m layer7 --l7proto bittorrent -j MARK >>--set-mark 1 iptables -t mangle -A lay7 -o eth1 -m mark --mark 1 -j >>CLASSIFY --set-class 2:2 iptables -t mangle -A lay7 -m layer7 --l7proto >>smtp -j MARK --set-mark 2 iptables -t mangle -A lay7 -o eth1 -m mark --mark >>2 -j CLASSIFY --set-class 2:3 iptables -t mangle -A lay7 -p tcp -m mark ! >>--mark 0 -j CONNMARK --save-mark >> >> >>If you're marking ever gets more complex, it might take a little more work >>( -j accepts for matching already classified connections after the >>--restore-mark) but the above should help get the full bittorrent >>connection classified, not just the first packet. >> >>- Jody >> >>Edgar wrote: >> >>>Hello, >>> >>>I've been trying to shape the bittorrent traffic (on my external >>>interface, upload), but without luck, for this I'm using layer7 filter >>>right now, but I've also tried ipp2p, with the same results, I might say >>>that this is not a problem with this packet classifiers, the problem is >>>with HTB, here's why. When I open azureus (the bittorrent client I use) I >>>see upload traffic getting shapped, but also I see that my download >>>traffic won't go up if I'm shaping
RE: [LARTC] Q: Routing the Same IP simultaneously on differentcomputers ?
Hi, First, never compare a linux box with a cheap and dumb broadband router. I'm not sure if i understand very well your scenario but I asume is like this: 192.168.0.1- ---| ipsec | | - 128.X.X.X - 192.168.0.254| ISP --| linux |--| - | - ---| voip | 192.168.0.2- You should read the iptables manpage, and your questions would have been already answered. Anyway here we go ... The nat table has 2 targets, SNAT and DNAT. SNAT alters source IP adresses and DNAT alters destination addreses. Netfilter can alter more protocols than tcp or udp. It can alter gre(protocol 57), used by pptp vpn, or even ipsec esp(proto 50) or ah(proto 51). How does it work ?! All packets pass through netfilter, you can google for a diagram, to see the order of traversal trough the tables/chains. But this concerns only the nat table so, the order is: PREROUTING, FORWARD, POSTROUTING. In the PREROUTING chain, we can alter the destianion of the packet, so : iptables -t nat -I PREROUTING -p 50 -d 128.x.x.x -j DNAT --to-destination 192.168.0.1 This will change the IPSEC ah packet's destination address to your lan ipsec host. I don't know if this is really functional. I'm not so familiar with ipsec ah, but should work, as far as routing/nat is concerned. As for the voip host. Let's say it uses TCP 5060 and UDP 5060. iptables -t nat -I PREROUTING -p tcp -d 128.x.x.x --dport 5060 -j DNAT --to-destination 192.168.0.1 iptables -t nat -I PREROUTING -p udp -d 128.x.x.x --dport 5060 -j DNAT --to-destination 192.168.0.1 In the POSTROUTING chain, we can alter the source of the packet so: As i understood, you've gone past this but here is an example... iptables -t nat -I POSTROUTING -s 192.168.0.1 -j SNAT --to-source 128.x.x.x This changes the source destination of the packet after the routing has taken place, so your private address is altered. This should do the trick. If you want to forward EVERYTHING to a host, the linux router cannot use the internet itself (acts as a stupid broadband router). This means, the routing works great, but the linux box itself can't estabilish any connection, since packets destinated to it is forwarded to a lan host. And this is not what we want. Success, Iosif Peterfi, S.C. Forte Systems SRL http://.fortesys.ro/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Wigley Sent: Tuesday, June 21, 2005 7:41 PM To: lartc@mailman.ds9a.nl Subject: [LARTC] Q: Routing the Same IP simultaneously on differentcomputers ? Hi, I've asked this elsewhere and received hints but no one seems to have a concrete explanation :- What I am looking to do is to be able to configure a Linux based router to be able to share THE SAME SINGLE Public IP address between the linux router and a single computer on the lan acting as the DMZ host (NOT normal NAT IP sharing !). So basically you have a linux router with two network ports, WAN and LAN. The router takes the single ISP assigned public IP address for it's WAN interface and then uses a non routable subnet for the LAN port. There are a number of machines on the LAN segment and the linux router is performing NAT for them so that they have internet connectivity - so far this is a standard normal setup. Now what I want to do is to simultaneously assign that SAME PUBLIC IP address onto one of the LAN computers so that it for all intents and purposes is a DMZ host. Before anyone says that this is mad and that it can't be done, it can be done perfectly well and all WESTELL ADSL / Ethernet routers have this functionality along with some no name Far Eastern origin broadband routers based on a Conexant OEM reference design. Having thought long and hard about how to do this but not knowing NetFilter at all, I realised that the way this must be done is for the router to perform a standard NAT function with the added functions of tracking all outgoing connections from the DMZ host and entering those into the NAT table as well, so that it doesn't try to do a Port Address Translation on top of an existing outgoing connection from the DMZ host. For incoming connections, if the incoming packet has a reference in the NAT table then it is directed to the originating LAN machine and if not is passed through unmodified to the DMZ host. I have spent much time googling and reading list postings but cannot find any reference on how to do this under linux, my guess is that Proxy ARP needs to be enabled on the LAN interface and then a 1:1 POST NAT mapping set to remap all the packets for the DMZ host back to the original public IP
RE: [LARTC] TC Filtering Problems
You got it the wrong way. Let me explain. Tc shapes outgoing packets, not incoming. So .. if you want to shape download, you have to shape it using eth0 interface. Add rules to match packets from source port 80 or destination lan/firewalled ip. ( this is why your download shaping works ) If you want to shape upload, you have to shape it using eth1 int. (this is where you should change some things ). Add rules to match packets to destination port 80 or source lan/firewalled ip using eht1. ( note that since shaping is done after the routing, the SNAT rules in iptables will be applied before shaping occurs.. so .. you can't shape outgoing packets by source using nat in the same time). Anyway .. if you don't like how tc works there is a kernel patch IMQ. Google for it... using it you can shape incoming packets, as they arrive on the interface. :D Iosif Peterfi Forte Systems S.R.L. http://www.fortesys.ro/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Bauer Sent: Wednesday, June 01, 2005 3:51 PM To: lartc@mailman.ds9a.nl Subject: [LARTC] TC Filtering Problems Dear Admins and Hackers, maybe i am to stupid to use 'tc'. But i having logical Problems to understand the Filter Rules in tc. Common Config: There is a Linux Engine (Debian) with a 2.6.11.11 Kernel which act as Packetshaper. Two Interfaces eth0 and eth1 are installed. Interface 'eth0' is the Firewall Side Net 195.185.185.0/24. Interface 'eth1' goes to the Internet (switch and Routers to the isps). Both Interfaces are bridged. The TEST Client is located on the eth0 Device of the Packetshaper. Kernel Module: (lsmod) Module Size Used by mirred 7744 0 sch_dsmark 7424 0 police 10976 0 pedit 7648 0 gact 7008 0 cls_rsvp 7424 0 cls_route 7808 0 sch_prio 5888 0 ipt_state 2048 0 ipt 8288 0 sch_htb 18816 0 cls_tcindex 8192 0 cls_u32 9220 0 cls_fw 5504 0 TC Config (a htb Qdisc): for d in eth0 eth1; do tc qdisc add dev $d root handle 1:0 htb default 12 tc class add dev $d parent 1:2 classid 1:2 htb rate 8096mbit tc class add dev $d parent 1:2 classid 1:10 htb rate 64kbit ceil 64kbit prio 0 tc class add dev $d parent 1:2 classid 1:12 htb rate 1024mbit ceil 1024mbit prio 0 done Http Filter ( looks for (Source)Port 80 on Offset 20 in the Ip Packet (Httpserver Answer) ): tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match u32 0x50 0x at 20 classid 1:10 This Filter is working and the http download on the Firewall Side is resticted to 64 kbit as you can see below. tc -s filter show dev eth0 : filter parent 1: protocol ip pref 100 u32 filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 151 success 129) match 0050/ at 20 (success 129 ) But why i !cant! filter Packets with dstPort 80 or Src Ip on eth0: Dstport 80: tc filter add dev eth0 parent 1:0 protocol ip prio 0 u32 match u32 0x50 0x at nexthdr+0 classid 1:10 or Source Ipaddress: tc filter add dev eth0 parent 1:0 protocol ip prio 0 u32 match ip src 195.185.185.2/32 classid 1:10 On these Filters are no success Counters. Our Firewall cant it be. I connect our Testlaptop directly to the eth0 Packetshaper Device. When i run a "tcpdump -i eth0" on the Packetshaper i saw the Src Ipaddress 195.185.185.2 and dstport 80 Packets. I cant understand why tc not able to find the SRC IP Fields in the Packets on eth0 of the Packetshaper. At first i thought the problem will be the br_fw (bridgerouter) Option in the Kernel. Without these Option the Problem is still alive. In my Eyes it´s not logical! Please can anyone help me? Have no Idea left. I hope there is a Hacker or Admin which can me tell the Filterlogic. thanks in advance Christian __ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://linux.bitdefender.com/ -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://linux.bitdefender.com/ -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://linux.bitdefender.com/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] FW: HFSC + ESFQ - class statistics
Andreas: Of course there are filter rules, but they are irelevant here. Thanks for the feedback Patrick. I tought so, but i wanted to make sure there's nothing wrong with my configuration. -Original Message- From: Patrick McHardy [mailto:[EMAIL PROTECTED] Sent: Monday, May 30, 2005 12:41 AM To: Forte Systems - Iosif Peterfi Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] FW: HFSC + ESFQ - class statistics Forte Systems - Iosif Peterfi wrote: > The tc show command doesn't create any sent/rate statistics for > 1: / 1:1 / 1:2 / 1:3 - Everything is 0 except the period indicators. > Sent bytes are shown in the period, but the rate is not shown. For the > rest of the classes Sent bytes and packets are shown, but rate is not > show here either. HFSC doesn't update statistics of upper classes because I didn't want to walk up the entire heirarchy for each packet just for statistics. Regards Patrick -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://linux.bitdefender.com/ -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://linux.bitdefender.com/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] FW: HFSC + ESFQ - class statistics
Hello,
First I want to point out that I’m not so familiar with HFSC, since there
not so much info online.
But here is my script:
${TC} class add
dev ${LAN_IFACE} parent 1:0 classid 1:1 hfsc ls rate 100mbit ul rate 100mbit
${TC} class add
dev ${LAN_IFACE} parent 1:1 classid 1:2 hfsc ls rate 90mbit ul rate 90mbit
${TC} class add
dev ${LAN_IFACE} parent 1:1 classid 1:3 hfsc ls rate 690kbit ul rate 690kbit
${TC} class add
dev ${LAN_IFACE} parent 1:3 classid 1:10 hfsc rt dmax 1ms rate 32kbit ls rate
690kbit #dns
${TC} class add
dev ${LAN_IFACE} parent 1:3 classid 1:20 hfsc rt dmax 2ms rate 256kbit ls dmax
3ms rate 690kbit #http int
${TC} class add
dev ${LAN_IFACE} parent 1:2 classid 1:25 hfsc rt dmax 100ms rate 10mbit ls dmax
100ms rate 80mbit #squid
${TC} class add
dev ${LAN_IFACE} parent 1:2 classid 1:30 hfsc rt dmax 200ms rate 80kbit ls dmax
500ms rate 80kbit #wan
${TC} class add
dev ${LAN_IFACE} parent 1:3 classid 1:40 hfsc rt dmax 20ms rate 32kbit ls dmax
500ms rate 690kbit #msn
${TC} class add
dev ${LAN_IFACE} parent 1:3 classid 1:50 hfsc rt dmax 200ms rate 32kbit ls dmax
500ms rate 690kbit # http bulk
${TC} class add
dev ${LAN_IFACE} parent 1:3 classid 1:60 hfsc rt dmax 500ms rate 32kbit ls dmax
3000ms rate 690kbit # the rest
${TC} qdisc add
dev ${LAN_IFACE} parent 1:10 handle 10: esfq hash dst perturb 10
${TC} qdisc add
dev ${LAN_IFACE} parent 1:20 handle 20: esfq hash dst perturb 10
${TC} qdisc add
dev ${LAN_IFACE} parent 1:25 handle 25: esfq hash dst perturb 10
${TC} qdisc add
dev ${LAN_IFACE} parent 1:30 handle 30: esfq hash dst perturb 10
${TC} qdisc add
dev ${LAN_IFACE} parent 1:40 handle 40: esfq hash dst perturb 10
${TC} qdisc add
dev ${LAN_IFACE} parent 1:50 handle 50: esfq hash dst perturb 10
${TC} qdisc add
dev ${LAN_IFACE} parent 1:60 handle 60: esfq hash dst perturb 10
# tc -s -d class show dev eth1
class hfsc 1: root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues
0)
rate 0bit 0pps backlog 0b 0p requeues 0
period 0 level 3
class hfsc 1:1 parent 1: ls m1 0bit d 0us m2 10Kbit ul
m1 0bit d 0us m2 10Kbit
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues
0)
rate 0bit 0pps backlog 0b 0p requeues 0
period 25105 work 9541169 bytes level 2
…..
class hfsc 1:60 parent 1:3 leaf 60: rt m1 0bit d 500.0ms m2
32008bit ls m1 0bit d 3.0s m2 69bit
Sent 7651774 bytes 16422 pkt (dropped 0, overlimits 0
requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
period 16413 work 7651774 bytes rtwork 1120698 bytes
level 0
The tc show
command doesn’t create any sent/rate statistics for 1: / 1:1 / 1:2
/ 1:3 – Everything is 0 except the period indicators. Sent bytes are
shown in the period, but the rate is not shown. For the rest of the classes
Sent bytes and packets are shown, but rate is not show here either.
This bug is
related to the kernel or iproute2 package?
Thanks
Iosif Peterfi
--
This message was scanned for spam and viruses by BitDefender.
For more information please visit http://linux.bitdefender.com/
--
This message was scanned for spam and viruses by BitDefender.
For more information please visit http://linux.bitdefender.com/
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
