Hi, I am currently using a script to shape my outbound ftp traffic. Works great except for 1 thing. When a user goes to list a dir, the listing is also getting shaped. This causes dir listings to be very slow. Is there a way to differentiate the dir listing packets? Here is a my current script: #!/bin/bash #shaping passive and active outbound ftp traffic on an internal computer without affecting inbound and lan speed # mark the outbound passive ftp packets on ports 50000-51000 iptables -t mangle -D OUTPUT -o eth0 -j MYSHAPER-OUT 2> /dev/null > /dev/null iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null iptables -t mangle -N MYSHAPER-OUT iptables -t mangle -I OUTPUT -o eth0 -j MYSHAPER-OUT iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 20 iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 59999 -j MARK --set-mark 26 iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK --set-mark 26 iptables -t mangle -A MYSHAPER-OUT -p tcp -m length --length :64 -j MARK --set-mark 30 # clear it tc qdisc del dev eth0 root #add the root qdisk tc qdisc add dev eth0 root handle 1: htb default 20 #add main rate limit class tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit #add leaf classes tc class add dev eth0 parent 1:1 classid 1:2 htb rate 100mbit tc class add dev eth0 parent 1:1 classid 1:3 htb rate 40kbps tc class add dev eth0 parent 1:3 classid 1:31 htb rate 30kbps ceil 40kbps prio 2 tc class add dev eth0 parent 1:3 classid 1:32 htb rate 10kbps ceil 34kbps prio 1 #filter traffic into classes tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:2 tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 26 fw flowid 1:31 tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 30 fw flowid 1:32 Thanks, Mark
nix4me wrote:> When a user goes to list a dir, the listing is also getting shaped. > This causes dir listings to be very slow. > Is there a way to differentiate the dir listing packets?Only if your ftp server software can send dir lists on different ports and/or with different IP TOS flags. If it doesn''t and you''re using open source software it shouldn''t be difficult to hack it yourself to set for example IPTOS_LOWDELAY when sending dir lists, then use iptables --tos to put it into a different class. See how OpenSSH sets IP TOS flags in packet.c: packet_set_tos() Toby -- UNIX is a lever for the intellect. -John R. Mashey
Toby wrote:>nix4me wrote: > > >>I have examined the packets leaving and i can''t seem to pin point which >>are the listings. I ran ethereal and then continually requested lists, >>the only packets i see leaving are coming from port 60000 which is the >>control port. >> >> > >As far as I know listings don''t go through the control port, they go >through one of the data ports, as if you were downloading a file. > >That''s why you cannot differentiate them from regular downloads, unless >the server software uses a different data port or different TOS flags or >something. > > >Toby > > >Yes, I see them now. They are indeed leaving on a shaped port range. And the packets are larger than the ACK size that I am putting at the head of the que. They seem to be 1450 in length. Mark
Another idea would be - if the directory which will be listed isn''t too large - that you use netfilters connbytes match. If less data are requested via ftp-data the will get a higher priority then bulk ftp-data. You can match with iptables and put them in the desired queues. Cheers, Andreas nix4me wrote:> Toby wrote: > >> nix4me wrote: >> >> >>> I have examined the packets leaving and i can''t seem to pin point >>> which are the listings. I ran ethereal and then continually >>> requested lists, the only packets i see leaving are coming from port >>> 60000 which is the control port. >>> >> >> >> As far as I know listings don''t go through the control port, they go >> through one of the data ports, as if you were downloading a file. >> >> That''s why you cannot differentiate them from regular downloads, unless >> the server software uses a different data port or different TOS flags or >> something. >> >> >> Toby >> >> >> > Yes, I see them now. They are indeed leaving on a shaped port range. > And the packets are larger than the ACK size that I am putting at the > head of the que. > > They seem to be 1450 in length. > > Mark > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc