P2P traffic not going into P2P queue
-
Hi, I've got all the rules for my traffic shaping set up with the right ports and everything, but for some reason BitTorrent traffic that's supposed to be going into the P2P queue goes into the default queue. Any advice?
-
Use the Catchall-Option for P2P when runing the Wizard. Some Clients use random ports or fall back to other well known ports.
-
I know the ports of my bittorrent clients (22182 and 18253.) They've been added into the traffic shaper config yet are still being fed into the P2P queue… and I'd rather not use p2pcatchall on the off chance that someone uses an unrecognized protocol that gets mixed in with the P2P traffic.
-
You probably have to reset states after changin trafficshaer configuration. Queues are assigned on initiating traffic, so if you want to completely apply a new ruleset to already established links you need to reset states.
-
Already done that. For some reason a little bit's going into the P2P queue but most seems to go into the default queue. Looking at the state table most is coming from my IP, 192.168.1.50:22812 but it doesn't seem to be shaped.
-
If the oposite end listens on port 80 or something else it might get caputured by one of the other rules. Rules are applied on a first match basis. Maybe you need to reorder some rules.
-
Most bittorrent clients use the specified ports for inbound connections only, outbound connections end up going out on random ports. The catchall is very useful for catching all the outgoing connections that aren't on your specified ports.
-
when you're using bittorrent, should the qwanacks queue go up a bit?
my qwanacks queue goes up to about 60Kb/s when i'm using bittorrent, the qP2PUp/Down queues seem to be catching all of the BT traffic though.
-
Every tcp traffic causes ACKs. As bittorrent causes quite a lot of connections it will cause some ACKs as well. This is normal.
-
Every tcp traffic causes ACKs. As bittorrent causes quite a lot of connections it will cause some ACKs as well. This is normal.
sounds good, that's what i expected, thanks hoba ;)
can I get in another quick question?
the traffic shaping seems to work great most of the time but sometimes i have the following problem, i'll start my torrent and then my web traffic will just not respond. but if i reload the filters the web traffic is fine and will be fine for the remainder of the torrent. this doesn't seem to happen all the time either. it looks like all queues are catching the right traffic. my http traffic is set to qOthersH (up/down) and right now it's got about 30% bandwidth. is there anything i can do to alleviate this??
sorry, turned out to be a pretty long question
-
Are you running out of states? At the statuspage how many states do you see there (should be something like x/10000). The default setting is 10000 states but you can raise this limit depending on RAM at system>advanced (nearly at the bottom of the page).
-
Are you running out of states? At the statuspage how many states do you see there (should be something like x/10000). The default setting is 10000 states but you can raise this limit depending on RAM at system>advanced (nearly at the bottom of the page).
oh, i didn't know that… what exactly are states? like the number of connections?
what will raising it do?edit: i have a P4 2.4 CPU and 512 RAM, how many states should I raise it to?
-
First check if you hit the limit at status>system. States are current connection, right. Unless you run a lot of packages or packages like snort you can savely bump the limit up to 20000 or 30000. Question is if that makes sense for your connection depending on speed.
-
First check if you hit the limit at status>system. States are current connection, right. Unless you run a lot of packages or packages like snort you can savely bump the limit up to 20000 or 30000. Question is if that makes sense for your connection depending on speed.
I think I do hit the limit when I do torrents. I'll try this tonight, would it help if I used those m1,d,m2 values in my qOthersHdown queue (the one that my HTTP rule is tied to)?
thanks so much for your help btw
-
These values don't affect the statelimit. Btw, you can see historical logs of states at status>rrd graphs, system, states (if running a more recent snapshot). This graph was added some time ago.
-
These values don't affect the statelimit. Btw, you can see historical logs of states at status>rrd graphs, system, states (if running a more recent snapshot). This graph was added some time ago.
hmm, i don't seem to have that graph, i'm running the latest stable version: "1.0.1
built on Sun Oct 29 01:07:16 UTC 2006"what do those values do then? they won't 'grab' states, because of priority, from the ones that are being used by P2P?
i'll check my states tonight, but i'm 99% sure my states were at the limit, i seem to recall that they might've even went over by a couple at times.
-
This version doesn't have this graph. Just bump up the states to a higher value and check when your bt traffic started going. If you then see more than 10000 states used it most likely was your problem. The values if the trafficshaper only affect the bandwidth that is assigned to a queue but not the amount of states causing it.
-
Sounds good, I'll post back about how it went, thanks again hoba. you've been very helpful
-
ok i'm back home and tried downloading a torrent, however, the torrent wasn't busy enough and didn't fill up my states so my surfing was fine… i think you were right about the problem of me running out of states, i think that's when my http traffic goes to sh1t. i will report back once i can do a proper test with a busy torrent.
-
hi hoba,
well, it seems like the states thing wasn't the problem. I think the problem is that my qOthersDownH queue starts getting a lot of drops when th qP2PDown queue starts heating up… and therefore i think this causes all the delay on my http traffic. Again, this only happens when the torrent is really busy, any suggestions??
thanks