[ previous ] [ next ] [ threads ]
 From:  "Mas Libman" <mas at masandwendy dot com>
 To:  "'Joseph & Katie Jackson'" <jkjackson at gmail dot com>, "'Gianluca Bosco'" <g dot bosco at bitache dot net>
 Cc:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] complete traffic shaping for azureus/BT
 Date:  Wed, 21 Dec 2005 11:05:35 -0800
The "Set Bittorrent traffic to the lowest priority" checkbox just creates a
set of default rules to shape the standard ports (6881-6999\etc). The
problem is that traffic can originate on any range of ports.

One thing that I have tried, which seems to be working OK, is to set a rule
below all other high-pri rules to put any TCP traffic coming in or out
through ports 1000-5000 as low pri (m_Hated Download).

Another aspect of shaping that I'm curious about is the NIC to which you
bind the rule. If you are making a rule that shapes outgoing traffic,
shouldn't it bind to the LAN, not the WAN? Outgoing traffic that binds to
the WAN will have already gone through NAT, thus changing its outgoing port.
However if you bind the rule to the LAN, where the traffic has not yet been
NAT'd, you have a better chance of specifying a relevant port range. Is this
correct thinking or am I off? (The autoshaping wizard binds everything to
the WAN.)


-----Original Message-----
From: Joseph & Katie Jackson [mailto:jkjackson at gmail dot com] 
Sent: Wednesday, December 21, 2005 7:08 AM
To: Gianluca Bosco
Cc: m0n0wall at lists dot m0n0 dot ch
Subject: Re: [m0n0wall] complete traffic shaping for azureus/BT

Why don't you just check the box that says "Set Bittorrent traffic to the
lowest priority"?

On 12/21/05, Gianluca Bosco <g dot bosco at bitache dot net> wrote:
> > In my home network, there is a traffic shaper rule that 
> > deprioritizes
> > 6881-6999 source traffic, and a separate rule that deprioritizes
> > 6881-6999 destination traffic. All is well for incoming connections, 
> > because the incoming Azureus ports in the network are within that 
> > port range. However, I think that there is trouble with outgoing 
> > connections going to non-standard ports. When I use TCPView, I see
> I had exactly the same problem with my Emule. The fact that Emule 
> clients could be configure to DO not use the standards ports, made my 
> traffic shaper rules almost useless.
> Following is the solution I came up with: block *all* the outgoing 
> connections as default, and allow only Emule connections to the 
> standard Emule ports.
> This made sure that, my emule connections where matched always by the 
> appropriate traffic shaper rules. The downside is that -- I´m not able 
> to connect to emule clients using non-standard ports -- but for me 
> this is acceptable.
> But still - I ask to the mailing list: Isn´t out there a traffic 
> shaping application that can match traffic depending on the type of 
> the highlevel-protocol? Something that can recognize "emule" packets, 
> "azureus" packets" (as many network analyzer do) instead of 
> classifying connections based on the classic sourceip/destinationip 
> sourceport/destinationport etc etc?
> -Gianluca Bosco
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> ----- End forwarded message -----
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch