-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Good morning,
: By classifier I think you mean:
: iptables -t mangle -A POSTROUTING -o ${IFext} -p tcp --dport 10000:10000 -j
: CLASSIFY --set-class 1:100
Exactly.
: And having looked at that, I see part of my problem. --dport should be
: --sport as I have no way to control what port
: the other client wishes to use, but I do have control over what ports I use
: to send my data stream.
Yes. We think about services (at TCP) as being on a standard port,
but iptables operates at L3 (even though it can examine higher
layers). So, if the packet in question is a return packet from an
HTTP server to a client, then as far as iptables is concerned, the
source port is tcp/80.
: I ran "tc filter" on the command line, but received no output in
: return. I read the man page and it leads me to believe that it's
: not meant for viewing the filters.
Depends, but yes, the "tc filter" output is not necessarily
attractive. You can classify with "tc filter" instead of iptables,
but if you reach your goal, it doesn't matter which mechanism you
use to classify your packets.
: One thing I did notice was, while I did see traffic in class 100
: for the first time, my torrent client still showed outgoing
: bandwidth of more than 20kbit.
Well, a typical torrent client will use a number of connections.
Perhaps some of the connections are classified correctly and some
are not?
: Is this simply a function of the router actually limiting the
: traffic and the torrent client simply not knowing? Or (and I
: assume this is incorrect thinking) should the torrent client
: visibly indicate to me that it can only send at X rate because
: its limited?
I would expect the torrent client to be reporting the actual
speed(s), so I would expect it to be reporting 20kbit rates.
: To make this much simpler, I will paste my tc rules and iptables
: rules (which classify my traffic) at the bottom of this e-mail. I
: hope you can find something (related specifically to bit torrent)
: that will allow me to limit torrent traffic without the need to
: limit each client by hand.
You are getting there.
: So I am at a total loss as to why (outgoing) SSH traffic would
: become so slow, because it has access to more bandwidth than
: torrent (at least in my thinking).
Are you sure that it's outgoing SSH traffic that is slow? Consider
the following scenario:
* your outgoing queues are configured completely correctly
* outgoing ssh IP packet gets into correct queue
* inbound return IP packet from ssh server is delayed inbound
because you are not shaping downstream traffic
So, before you conclude that your shaping isn't working, I think
you'll need to apply some sort of mechanisms also on your internal
interface.
Snipped iptables classification. Nothing looks fishy to me there
(though I haven't used the iptables CLASSIFY target).
: $IFext is of course eth0 (link to the modem), $QUANTUM is 1490
: (due to, if I assume correctly, my MTU being 1492, in the modem),
: $MAX_RATE is 360kbit (360kbps conventional talk)
I wouldn't set quantum unless you need to do so. HTB will calculate
this for you. If you do need to set the quantum, I'd recommend
setting it just a bit larger than the MTU...so 1500 or 1536 in your
pppoe situation.
Good luck,
- -Martin
- --
Martin A. Brown
http://linux-ip.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/)
iD8DBQFG3Vd1HEoZD1iZ+YcRAv0pAKDZ0qtpxyOkGJJQ7H5rWtFi3HlM2gCgrugd
WyARMeCjVI9TD/1CcTTDAsw=
=RKrP
-----END PGP SIGNATURE-----
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
