Still having problems with shaping…
-
Hi again,
I finally figured out why my shaping dos not work as I thought it would do.
The fact is that the Bit Torrent application I'm using (and probably allot of other Bit Torrent applications as well) selects a random port for outgoing connections. This means that the "handshake" is made on the specified port but the actual data transfer is made on any port randomly selected. That is why my "outgoing" traffic gets jammed up when letting my Bit Torrent client use "all" bandwidth (with the intent to let the traffic shaper in pfSense handle the limitation. It actually don't shape the outgoing traffic because it goes on "random ports". :(So, the next question then becomes…
Is there by any chance a possibility that you will add the application layer to the traffic shaper? 8) That would basically solve all the problems. But, of course create a tremendous amount of work for you guys... :/ -
Yeah there is layer 7 traffic shaping work going on for pfSense so you can look forward to that in the future.
In the meantime what I can suggest as a work around is to prioritize the traffic for well know ports (VNC, WEB, SMTP, POP3, etc..)
then create a low priority queue where everything else gets pushed into regardless of port number. Everything that is
not explicitly tagged by the shaper goes to the default queue, so giving that (qWANdef) a lower priority should make
other traffic smoother. -
Hi again,
I finally figured out why my shaping dos not work as I thought it would do.
The fact is that the Bit Torrent application I'm using (and probably allot of other Bit Torrent applications as well) selects a random port for outgoing connections. This means that the "handshake" is made on the specified port but the actual data transfer is made on any port randomly selected. That is why my "outgoing" traffic gets jammed up when letting my Bit Torrent client use "all" bandwidth (with the intent to let the traffic shaper in pfSense handle the limitation. It actually don't shape the outgoing traffic because it goes on "random ports". :(So, the next question then becomes…
Is there by any chance a possibility that you will add the application layer to the traffic shaper? 8) That would basically solve all the problems. But, of course create a tremendous amount of work for you guys... :/At some point…maybe. Here's an interesting hack I did to catch all P2P on my network.
Run the wizard selecting options as usual (ensure that you select "common" items like HTTP even if you want them "default" - you'll see why in a minute)
Modify both BitTorrent rules to any port
Move both BitTorrent rules to the LAST rule in your rulesetThe shaper is first match..by putting an "any" rule at the bottom you have just added a catch-all rule. This will nail ALL your P2P along with ALL other traffic that doesn't have explicit rules for it. Works like a champ (until some putz runs hit BT on port 80 - which does happen from time to time).
--Bill
-
As of the 04-02-2006 snapshot (todays) this option is now included on the p2p screen called p2pCatchAll.
-
Ah, nice! :)
Is this also included in the 04-03-2006 snapshot or should I wait with that one? -
Yep, it's already included in this snapshot.
-
Ah, nice! :)
Is this also included in the 04-03-2006 snapshot or should I wait with that one?As of the 04-02-2006 snapshot (todays) this option is now included on the p2p screen called p2pCatchAll. (ps: could this post have been any more clear!?!?!?!)
-
Well, sorry, I am not native English….
For me it could also meant that it was included in (todays only) snapshot for test purposes. Because of the trouble we (I) have had. Sorry, I will try to shape up! :) -
Well, sorry, I am not native English….
For me it could also meant that it was included in (todays only) snapshot for test purposes. Because of the trouble we (I) have had. Sorry, I will try to shape up! :)Heh…I love how dates get swapped :) Is 04-03-2006 April 3rd or March 4th? :) It's obvious to both Brits and Yanks...it's obvioulsy April 3rd to me duck..
--Bill
-
Heh, I see the disconnect now.
Over here we go by MM-DD-YYYY.
-
one question about the catch-all idea…
doesnt this screw with http traffic?
don't most browsers use a random high port to initiate data transfer of page contents...?
e.g.
myPC:52345 -> google.com:80 (matches QoS rule for http)
then remote server responds to the request on the port initiated with the actual page contents.
google.com:?? -> myPC:52345 (matches catch-all rule and gets treated as P2P?)so the QoS works only one way...?
probably other things besides http work in a similar way... i am no expert though so i'm hoping you will tell me i'm wrong and traffic will be recognized fine and shaped. of course, my choke point is the outgoing b/w not the incoming so i still added the catch-all rule. but if i am right then perhaps i should only add the outgoing catch-all? err.. hmm.. now i think i confused myself.
-
That connection belongs to the same state and will be treated the same way like the outgoing request.