Hello! I am trying to configure Shorewall + Wondershaper, in a rather blatantly simple way. I want to differentiate p2p traffic in my small network from non-p2p traffic (dns, http(s), ssh, vnc) that is more latency sensitive. However, most isps (at least down here) try to block p2p traffic, and hence p2p software seems to try quite hard to make its traffic difficult to isolate. So I came out with this rather dubiously brillant configuration: 1) In the file tcrules, have a rule for each one of the latency sensitive protocols (using its well known tcp port), and mark them. 2) Insert suitable definitions in the script tcstart, mapping the traffic classes defined in 1 to different service classes. I followed some smart fellow''s online advice and based my tcstart script on Wondershaper. Well, this works quite well, and I can surf the web reasonably fast, even with the p2p swarm over my head. BUT tcp connections seem to take a long time to establish. Once a connection has been established and kept open in the browser, things go fine. Same for ssh, etc. So I poked around with ethereal a bit, and my feeling is that the initial SYN packet is not being flagged into the right service class by my tcrules settings. I have seen other people''s scripts flagging SYN,ACK,RST explicitly when using iptables directly. So here is my question: do you know of a way to mark SYN,ACK,etc. packages within the framework presented by Shorewall? Looking at the format of the tcrules file, that doesn''t seem very likely. Perhaps there is a file to add custom iptables commands? I have been using Shorewall since version 1.4, it is very nice. The idea of incorporating traffic shaping capabilities is, well, great. Perhaps integrating it a bit more with something simple like Wondershaper would be even better! Regards, and apologies for a tiresome post! Santiago ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
Santiago Bazerque wrote:> ... > I have been using Shorewall since version 1.4, it is very nice. The > idea of incorporating traffic shaping capabilities is, well, great. > Perhaps integrating it a bit more with something simple like > Wondershaper would be even better!Tom and Arne are working on integrating Arne''s tc4shorewall into the 3.0 release. See the shorewall-devel list archives for details. There is a beta version you can test at http://shorewall.net/pub/shorewall/3.0/shorewall-3.0.0-Beta1/ (and the usual mirrors). Paul ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
Paul Gear escribió:> > Tom and Arne are working on integrating Arne''s tc4shorewall into the 3.0 > release. See the shorewall-devel list archives for details. There is a > beta version you can test at > http://shorewall.net/pub/shorewall/3.0/shorewall-3.0.0-Beta1/ (and the > usual mirrors). > > PaulBTW.. beta version works fine, I manage a firewall with beta1 on a production system and I found no problems. Give it a try, and if you have problems, firsts read the documentation,post your problem on the shorewall-devel list or join us at #shorewall on freenode. ;) -- Cristian Rodriguez R. perl -e ''$_=pack(c5,0105,0107,0123,0132,(1<<3)+2);y[A-Z][N-ZA-M];print;''
Paul and Judas, thanks for your replies! I am on 3.0-RC1 now, and able to formulate my query a little bit better under its traffic-shaping framework. Looking at the OPTIONS field in the tcclasses file, there is a tcp-ack flag used to gather all the ack packets (ACK bit = 1) in a given class (considering size restrictions) to accelerate downloads. I would like to add support for a tcp-syn flag that would do the same for packets with the SYN bit on, hoping to accelerate connection establishment under heavy network load. I think I should add a line similar to list_search "tcp-ack" $options && ensure_and_save_command tc filter add dev $device parent $devnum:0 protocol ip prio 10 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid $classid replacing tcp-syn for tcp-ack and changing one of those masks accordingly, something like this perhaps: list_search "tcp-syn" $options && ensure_and_save_command tc filter add dev $device parent $devnum:0 protocol ip prio 10 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x02 0xff at 33 flowid $classid (changed the 33rd byte to 0x02, instead of 0x10, to match SYNs). I should change the tcclasses validation function as well, but that looks like chicken-class local-understanding-only programming. No mental parsing of low level network protocol headers involved :-) Ok, I am trying it out and it seems to work fine, I don''t know if giving SYN packets the same special treatment one gives ACKs makes much sense, anyway. cheers, Santiago ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
On Tuesday 18 October 2005 21:23, Santiago Bazerque wrote:> > Ok, I am trying it out and it seems to work fine, I don''t know if > giving SYN packets the same special treatment one gives ACKs makes > much sense, anyway.I suggest that if you plan to hack away on the traffic shaping code that you download the original tc4shorewall -- it runs as an external tcstart script. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key