[LARTC] shareaza

[LARTC] shareaza

[ncrfgs]

[-- Attachment #1.1: Type: text/plain, Size: 2314 bytes --]

Hi,

A, B and C are three machines. A and C directly access to
theInternet while B access to the Internet through A.

 +-------------------------------------------------------------+
 | +-------------+                             +-------------+ |
 | |      A      |                             |      B      | |
 | |             | --- eth0 ---> <--- eth0 --- |             | |
 | | 192.168.0.1 |                             | 192.168.0.2 | |
 | +-------------+                             +-------------+ |
 +-------------------------------------------------------------+
          |
         ppp0
          |
          v
       Internet
          ^
          |
        +---+
        | C |
        +---+

A runs GNU/Linux and is configured to MASQUERADE B and in
such a way that packets incoming on ppp0 are DROP'd unless
their state is either ESTABLISHED or RELATED or unless
their destination is port 6346 (both tcp and udp), in which
case they are redirected to B.

B runs Shareaza, a P2P that is able to access several kind
of networks such as edonkey, gnutella and gnutella2 and it
should only use port 6346.


I'd like to shape outgoing traffic, that is, I'd like to
limit the bandwidth B uses to upload files over the
Internet.

I'm sharing the connection with other individuals and I
don't have much control over B... I only have very little
informations about it, sorry, and most of them comes from
tcpdump.


If B uploads a file to C through gnutella everything works
like a charm since packets look just like this:

 192.168.0.2:6346 > xxx.xxx.xxx.xxx:yyyyy

With tc I filter packets whose source port is 6346 and
everything is fine.


Problems come when B uploads a file to C through edonkey.
Packets don't always look like the former ones. Sometimes
the source port is 6346 in this case as well, but more
often they look like this:

 192.168.0.2:zzzzz > xxx.xxx.xxx.xxx:4662

Port 4662 is the most common one but it isn't always the
same.


How can I work around it?



Thanks in advance.

Best regards.
-- 
Value your freedom, or you will lose it, teaches history.
``Don't bother us with politics,'' respond those who don't
want to learn.

 -- Richard M. Stallman
    http://www.gnu.org/philosophy/linux-gnu-freedom.html

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] shareaza

[Georgi Alexandrov]

ncrfgs wrote:

>Hi,
>
>A, B and C are three machines. A and C directly access to
>theInternet while B access to the Internet through A.
>
> +-------------------------------------------------------------+
> | +-------------+                             +-------------+ |
> | |      A      |                             |      B      | |
> | |             | --- eth0 ---> <--- eth0 --- |             | |
> | | 192.168.0.1 |                             | 192.168.0.2 | |
> | +-------------+                             +-------------+ |
> +-------------------------------------------------------------+
>          |
>         ppp0
>          |
>          v
>       Internet
>          ^
>          |
>        +---+
>        | C |
>        +---+
>
>A runs GNU/Linux and is configured to MASQUERADE B and in
>such a way that packets incoming on ppp0 are DROP'd unless
>their state is either ESTABLISHED or RELATED or unless
>their destination is port 6346 (both tcp and udp), in which
>case they are redirected to B.
>
>B runs Shareaza, a P2P that is able to access several kind
>of networks such as edonkey, gnutella and gnutella2 and it
>should only use port 6346.
>
>
>I'd like to shape outgoing traffic, that is, I'd like to
>limit the bandwidth B uses to upload files over the
>Internet.
>
>I'm sharing the connection with other individuals and I
>don't have much control over B... I only have very little
>informations about it, sorry, and most of them comes from
>tcpdump.
>
>
>If B uploads a file to C through gnutella everything works
>like a charm since packets look just like this:
>
> 192.168.0.2:6346 > xxx.xxx.xxx.xxx:yyyyy
>
>With tc I filter packets whose source port is 6346 and
>everything is fine.
>
>
>Problems come when B uploads a file to C through edonkey.
>Packets don't always look like the former ones. Sometimes
>the source port is 6346 in this case as well, but more
>often they look like this:
>
> 192.168.0.2:zzzzz > xxx.xxx.xxx.xxx:4662
>
>Port 4662 is the most common one but it isn't always the
>same.
>
>
>How can I work around it?
>
>
>
>Thanks in advance.
>
>Best regards.
>  
>
You can classify the traffic from B going out trough ppp0 with 
netfilter/iptables like this:
iptables -t mangle -A POSTROUTING -o ppp0 -s 192.168.0.2 -j CLASSIFY 
--set-class 0001:0010

And then shape it:

tc qdisc del dev ppp0 root
tc qdisc add dev ppp0 root handle 1: htb
tc class add dev ppp0 parent 1: classid 1:1 htb rate 128kbit
tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 128kbit
tc qdisc add dev ppp0 parent 1:10 handle 10: sfq perturb 10

that's for 128kbits/sec upload from 192.168.0.2.
I've attached a sfq to the htb class for "smoothness".


regards,
Georgi Alexandrov
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] shareaza

[ncrfgs]

[-- Attachment #1.1: Type: text/plain, Size: 1140 bytes --]

On Sun, Dec 11, 2005 at 05:30:55PM +0200, Georgi Alexandrov wrote:
> > If B uploads a file to C through gnutella everything works
> > like a charm since packets look just like this:
> >
> >  192.168.0.2:6346 > xxx.xxx.xxx.xxx:yyyyy
> >
> > With tc I filter packets whose source port is 6346 and
> > everything is fine.
> 
> You can classify the traffic from B going out trough ppp0 with 
> netfilter/iptables like this:

What you wrote is indeed very similar to what I use right 
now except for the fact that I'm classifying according to
the source port, too.

The side effect of your configuration is that all of the
traffic from B though ppp0 is shaped. The configuration
you've suggested is interesting but I'd like to limit the
shareaza traffic only.

Is there any way to do that? How can I keep track of the
traffic generated by shareaza only?



Thanks in advance.

Best regards.
-- 
Value your freedom, or you will lose it, teaches history.
``Don't bother us with politics,'' respond those who don't
want to learn.

 -- Richard M. Stallman
    http://www.gnu.org/philosophy/linux-gnu-freedom.html

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] shareaza

[Andreas Unterkircher]

I'm not very familar with all these p2p protocols. But isn't shareaza 
supporting all the other p2p protocols? Like edonkey and bittorrent...
Most of them can be matched with ipp2p (www.ipp2p.org) or l7-filter 
(l7-filter.sf.net).

ncrfgs schrieb:
> On Sun, Dec 11, 2005 at 05:30:55PM +0200, Georgi Alexandrov wrote:
>   
>>> If B uploads a file to C through gnutella everything works
>>> like a charm since packets look just like this:
>>>
>>>  192.168.0.2:6346 > xxx.xxx.xxx.xxx:yyyyy
>>>
>>> With tc I filter packets whose source port is 6346 and
>>> everything is fine.
>>>       
>> You can classify the traffic from B going out trough ppp0 with 
>> netfilter/iptables like this:
>>     
>
> What you wrote is indeed very similar to what I use right 
> now except for the fact that I'm classifying according to
> the source port, too.
>
> The side effect of your configuration is that all of the
> traffic from B though ppp0 is shaped. The configuration
> you've suggested is interesting but I'd like to limit the
> shareaza traffic only.
>
> Is there any way to do that? How can I keep track of the
> traffic generated by shareaza only?
>
>
>
> Thanks in advance.
>
> Best regards.
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>   

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] shareaza

[Georgi Alexandrov]

ncrfgs wrote:

>On Sun, Dec 11, 2005 at 05:30:55PM +0200, Georgi Alexandrov wrote:
>  
>
>>>If B uploads a file to C through gnutella everything works
>>>like a charm since packets look just like this:
>>>
>>> 192.168.0.2:6346 > xxx.xxx.xxx.xxx:yyyyy
>>>
>>>With tc I filter packets whose source port is 6346 and
>>>everything is fine.
>>>      
>>>
>>You can classify the traffic from B going out trough ppp0 with 
>>netfilter/iptables like this:
>>    
>>
>
>What you wrote is indeed very similar to what I use right 
>now except for the fact that I'm classifying according to
>the source port, too.
>
>The side effect of your configuration is that all of the
>traffic from B though ppp0 is shaped. The configuration
>you've suggested is interesting but I'd like to limit the
>shareaza traffic only.
>
>Is there any way to do that? How can I keep track of the
>traffic generated by shareaza only?
>
>
>
>Thanks in advance.
>
>Best regards.
>  
>
Perhaps you need something like l7-filter.sf.net ?


Georgi Alexandrov

Re: [LARTC] shareaza

[ncrfgs]

[-- Attachment #1.1: Type: text/plain, Size: 1039 bytes --]

On Sun, Dec 11, 2005 at 06:12:59PM +0100, Andreas Unterkircher wrote:
> I'm not very familar with all these p2p protocols. But
> isn't shareaza supporting all the other p2p protocols?
> Like edonkey and bittorrent...
> Most of them can be matched with ipp2p (www.ipp2p.org)
> or l7-filter (l7-filter.sf.net).

As far as I know they can but I wondered whether it was
possible to accomplish the task using only vanilla iptables
and iproute.

It looks like it works like this: shareaza ``negotiate''
with the other end listening on port 6346, then they try to
``find an agreement'' about which other port to use and in
the end uploads actually occurs on that one. Am I right?

Generally speaking, how can I recognize and keep track of
edonkey connections?



Thanks in advance.

Best regards.
-- 
Value your freedom, or you will lose it, teaches history.
``Don't bother us with politics,'' respond those who don't
want to learn.

 -- Richard M. Stallman
    http://www.gnu.org/philosophy/linux-gnu-freedom.html

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] shareaza

[Leonardo Rodrigues Magalhães]

>>
>> Is there any way to do that? How can I keep track of the
>> traffic generated by shareaza only?
>>
> Perhaps you need something like l7-filter.sf.net ?
>

    Maybe l7-filter is not necessary. For classifying P2P traffic, you 
can use ipp2p module, available through patch-o-matic or newest code 
from here http://ipp2p.org/ !

    Seems that Shareaza is matched with --gnu !!



[root@correio ~]# iptables -m ipp2p --help
[ ........ ]
IPP2P v0.7.2 options:
 --ipp2p        Grab all known p2p packets
 --ipp2p-data   Identify all known p2p download commands (obsolete)

 --edk          [TCP&UDP]       All known eDonkey/eMule/Overnet packets
 --dc           [TCP]           All known Direct Connect packets
 --kazaa        [TCP&UDP]       All known KaZaA packets
 --gnu          [TCP&UDP]       All known Gnutella packets
 --bit          [TCP&UDP]       All known BitTorrent packets
 --apple        [TCP]           All known AppleJuice packets (beta - 
just a few tests until now)
 --winmx        [TCP]           All known WinMX (beta - need feedback)
 --soul         [TCP]           All known SoulSeek (beta - need feedback!)
 --ares         [TCP]           All known Ares - use with DROP only 
(beta - need feedback!)

 --edk-data     [TCP]           eDonkey/eMule/Overnet download commands 
(obsolete)
 --dc-data      [TCP]           Direct Connect download command (obsolete)
 --kazaa-data   [TCP]           KaZaA download command (obsolete)
 --gnu-data     [TCP]           Gnutella download command (obsolete)

Note that the follwing options will have the same meaning:
 '--ipp2p' is equal to '--edk --dc --kazaa --gnu'
 '--ipp2p-data' is equal to '--edk-data --dc-data --kazaa-data --gnu-data'

IPP2P was intended for TCP only. Due to increasing usage of UDP we 
needed to change this.
You can now use -p udp to search UDP packets only or without -p switch 
to search UDP and TCP packets.

See README included with this package for more details or visit 
http://www.ipp2p.org

Examples:
 iptables -A FORWARD -m ipp2p --ipp2p -j MARK --set-mark 0x01
 iptables -A FORWARD -p udp -m ipp2p --kazaa --bit -j DROP
 iptables -A FORWARD -p tcp -m ipp2p --edk --soul -j DROP

iptables -m ipp2p --help                       
[root@correio ~]#

-- 


	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia
	http://www.solutti.com.br

	Minha armadilha de SPAM, NÃO mandem email
	gertrudes@solutti.com.br
	My SPAMTRAP, do not email it

Re: [LARTC] shareaza

[Andreas Unterkircher]

I guess it's not possible without knowing the nature of these protocols. 
It's like the ftp-data
channel... without looking into the ftp-cmd channel (ip_conntrack_ftp) 
iptables wouldn't
know that the two connections are related...

ncrfgs schrieb:
> On Sun, Dec 11, 2005 at 06:12:59PM +0100, Andreas Unterkircher wrote:
>   
>> I'm not very familar with all these p2p protocols. But
>> isn't shareaza supporting all the other p2p protocols?
>> Like edonkey and bittorrent...
>> Most of them can be matched with ipp2p (www.ipp2p.org)
>> or l7-filter (l7-filter.sf.net).
>>     
>
> As far as I know they can but I wondered whether it was
> possible to accomplish the task using only vanilla iptables
> and iproute.
>
> It looks like it works like this: shareaza ``negotiate''
> with the other end listening on port 6346, then they try to
> ``find an agreement'' about which other port to use and in
> the end uploads actually occurs on that one. Am I right?
>
> Generally speaking, how can I recognize and keep track of
> edonkey connections?
>
>
>
> Thanks in advance.
>
> Best regards.
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>   

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] shareaza

[Georgi Alexandrov]

ncrfgs wrote:

>On Sun, Dec 11, 2005 at 05:30:55PM +0200, Georgi Alexandrov wrote:
>  
>
>>>If B uploads a file to C through gnutella everything works
>>>like a charm since packets look just like this:
>>>
>>> 192.168.0.2:6346 > xxx.xxx.xxx.xxx:yyyyy
>>>
>>>With tc I filter packets whose source port is 6346 and
>>>everything is fine.
>>>      
>>>
>>You can classify the traffic from B going out trough ppp0 with 
>>netfilter/iptables like this:
>>    
>>
>
>What you wrote is indeed very similar to what I use right 
>now except for the fact that I'm classifying according to
>the source port, too.
>
>The side effect of your configuration is that all of the
>traffic from B though ppp0 is shaped. The configuration
>you've suggested is interesting but I'd like to limit the
>shareaza traffic only.
>
>Is there any way to do that? How can I keep track of the
>traffic generated by shareaza only?
>
>
>
>Thanks in advance.
>
>Best regards.
>  
>
Perhaps you need something like l7-filter.sf.net ?


Georgi Alexandrov

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] shareaza

[Georgi Alexandrov]

Leonardo Rodrigues Magalhães wrote:

>
>>>
>>> Is there any way to do that? How can I keep track of the
>>> traffic generated by shareaza only?
>>>
>> Perhaps you need something like l7-filter.sf.net ?
>>
>
> Maybe l7-filter is not necessary. For classifying P2P traffic, you can 
> use ipp2p module, available through patch-o-matic or newest code from 
> here http://ipp2p.org/ !
>
> Seems that Shareaza is matched with --gnu !!
>
>
>
> [root@correio ~]# iptables -m ipp2p --help
> [ ........ ]
> IPP2P v0.7.2 options:
> --ipp2p Grab all known p2p packets
> --ipp2p-data Identify all known p2p download commands (obsolete)
>
> --edk [TCP&UDP] All known eDonkey/eMule/Overnet packets
> --dc [TCP] All known Direct Connect packets
> --kazaa [TCP&UDP] All known KaZaA packets
> --gnu [TCP&UDP] All known Gnutella packets
> --bit [TCP&UDP] All known BitTorrent packets
> --apple [TCP] All known AppleJuice packets (beta - just a few tests 
> until now)
> --winmx [TCP] All known WinMX (beta - need feedback)
> --soul [TCP] All known SoulSeek (beta - need feedback!)
> --ares [TCP] All known Ares - use with DROP only (beta - need feedback!)
>
> --edk-data [TCP] eDonkey/eMule/Overnet download commands (obsolete)
> --dc-data [TCP] Direct Connect download command (obsolete)
> --kazaa-data [TCP] KaZaA download command (obsolete)
> --gnu-data [TCP] Gnutella download command (obsolete)
>
> Note that the follwing options will have the same meaning:
> '--ipp2p' is equal to '--edk --dc --kazaa --gnu'
> '--ipp2p-data' is equal to '--edk-data --dc-data --kazaa-data --gnu-data'
>
> IPP2P was intended for TCP only. Due to increasing usage of UDP we 
> needed to change this.
> You can now use -p udp to search UDP packets only or without -p switch 
> to search UDP and TCP packets.
>
> See README included with this package for more details or visit 
> http://www.ipp2p.org
>
> Examples:
> iptables -A FORWARD -m ipp2p --ipp2p -j MARK --set-mark 0x01
> iptables -A FORWARD -p udp -m ipp2p --kazaa --bit -j DROP
> iptables -A FORWARD -p tcp -m ipp2p --edk --soul -j DROP
>
> iptables -m ipp2p --help [root@correio ~]#
>
I messed it up (sorry list). That was for the lartc mailing list.
I guess I need to shorten the number of lists that I'm subscribed to ;-)


Georgi Alexandrov

P.S.
You're right. ipp2p can also do the trick.