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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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
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 _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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 >
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 _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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 >
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