Still having problems with shaping…

billm

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 ruleset

The 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

sullrich

As of the 04-02-2006 snapshot (todays) this option is now included on the p2p screen called p2pCatchAll.

Snille

Ah, nice! :)
Is this also included in the 04-03-2006 snapshot or should I wait with that one?

hoba

Yep, it's already included in this snapshot.

sullrich

@Snille:

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!?!?!?!)

Snille

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! :)

billm

@Snille:

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

sullrich

Heh, I see the disconnect now.

Over here we go by MM-DD-YYYY.

mOjO

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.

hoba

That connection belongs to the same state and will be treated the same way like the outgoing request.