Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    P2P traffic not going into P2P queue

    Traffic Shaping
    7
    30
    11920
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      meh last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • H
        hoba last edited by

        Use the Catchall-Option for P2P when runing the Wizard. Some Clients use random ports or fall back to other well known ports.

        1 Reply Last reply Reply Quote 0
        • M
          meh last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • H
            hoba last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • M
              meh last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • H
                hoba last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • M
                  Mersault last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • P
                    pookguy88 last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • H
                      hoba last edited by

                      Every tcp traffic causes ACKs. As bittorrent causes quite a lot of connections it will cause some ACKs as well. This is normal.

                      1 Reply Last reply Reply Quote 0
                      • P
                        pookguy88 last edited by

                        @hoba:

                        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

                        1 Reply Last reply Reply Quote 0
                        • H
                          hoba last edited by

                          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).

                          1 Reply Last reply Reply Quote 0
                          • P
                            pookguy88 last edited by

                            @hoba:

                            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?

                            1 Reply Last reply Reply Quote 0
                            • H
                              hoba last edited by

                              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.

                              1 Reply Last reply Reply Quote 0
                              • P
                                pookguy88 last edited by

                                @hoba:

                                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

                                1 Reply Last reply Reply Quote 0
                                • H
                                  hoba last edited by

                                  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.

                                  1 Reply Last reply Reply Quote 0
                                  • P
                                    pookguy88 last edited by

                                    @hoba:

                                    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.

                                    1 Reply Last reply Reply Quote 0
                                    • H
                                      hoba last edited by

                                      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.

                                      1 Reply Last reply Reply Quote 0
                                      • P
                                        pookguy88 last edited by

                                        Sounds good, I'll post back about how it went, thanks again hoba. you've been very helpful

                                        1 Reply Last reply Reply Quote 0
                                        • P
                                          pookguy88 last edited by

                                          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.

                                          1 Reply Last reply Reply Quote 0
                                          • P
                                            pookguy88 last edited by

                                            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

                                            1 Reply Last reply Reply Quote 0
                                            • H
                                              hoba last edited by

                                              What does your ack queues look like when under load? Try bumping up the ack queue a few percentages. Acks shouldn't get dropped if possible.

                                              1 Reply Last reply Reply Quote 0
                                              • P
                                                pookguy88 last edited by

                                                my ack queues look fine under load… but i'll have another look tonight, i know my qwanacks queue is fine. not too sure how my qlanacks is, I remember that I bumped the qlanacks queue too much once and it choked everything so I had to bring it back down.

                                                1 Reply Last reply Reply Quote 0
                                                • P
                                                  pookguy88 last edited by

                                                  yep, my ack queues were fine… my states were fine, like under 5000 the only thing that looked out of the ordinary was that the qOthersDownH queue had quite a few drops, like about 100 something...

                                                  1 Reply Last reply Reply Quote 0
                                                  • P
                                                    pookguy88 last edited by

                                                    well, i tried moving the http rule to the top of the rule list… maybe that will make a difference... the P2P catch-all rule as at the bottom

                                                    1 Reply Last reply Reply Quote 0
                                                    • P
                                                      pookguy88 last edited by

                                                      hoba,

                                                      I seem to have run into that slow down again tonight, what seems to be happening is my qOthersDownH queue doesn't seem to want to 'take' the bandwidth away from my qP2PDown queue when it's maxed. Like it's being blocked or something, it doesn't want to take it's percentage of the bandwidth… any suggestions?? thanks again

                                                      edit: it seems when I reload my rules/queues it seems to clear up the 'blocking'.... like, the shaper works without hiccups when I reload the queues during a P2P download.

                                                      1 Reply Last reply Reply Quote 0
                                                      • S
                                                        sullrich last edited by

                                                        @pookguy88:

                                                        hoba,

                                                        I seem to have run into that slow down again tonight, what seems to be happening is my qOthersDownH queue doesn't seem to want to 'take' the bandwidth away from my qP2PDown queue when it's maxed. Like it's being blocked or something, it doesn't want to take it's percentage of the bandwidth… any suggestions?? thanks again

                                                        edit: it seems when I reload my rules/queues it seems to clear up the 'blocking'.... like, the shaper works without hiccups when I reload the queues during a P2P download.

                                                        Are you using miniupnp by chance?

                                                        1 Reply Last reply Reply Quote 0
                                                        • P
                                                          pookguy88 last edited by

                                                          @sullrich:

                                                          Are you using miniupnp by chance?

                                                          nope… should I be?

                                                          1 Reply Last reply Reply Quote 0
                                                          • S
                                                            sullrich last edited by

                                                            Just checking.

                                                            1 Reply Last reply Reply Quote 0
                                                            • T
                                                              The Printer Elf last edited by

                                                              Any more ideas on this one?
                                                              I'm having similar troubles, although possibly not in the usual way that one would expect to use the connection.
                                                              I have people downloading some pretty hefty files from me, but when that's not the case, I'd like BT to be using the upstream connection as best it can. I'm using μtorrent, it's set to use just one port, and I've currently got the scheduler set to ensure that there is some bandwidth available when I'm actually home and want to use the connection, as I can't seem to get the traffic shaper function the way I desire.
                                                              I'm quite willing to admit that I could well be being dim, and it's doing exactly what it's designed to do, I just haven't configured it correctly.
                                                              I've altered the qP2PUp and qP2PDown rules accordingly to reflect the port that μtorrent is targeted at, I've placed them at the top of the rules list, so there should be nothing stopping the traffic getting identified appropriately, and I've lowered the queue priorities and realtime bandwidth as much as is possible.
                                                              My problem is thus: I have a max upstream b/w of approx 55kB/s, and I've got μtorrent restricted to 50kB/s, yet when someone starts an HTTP download from me, I would expect μtorrent to grind to a halt, and ~55kB/s to be achieved, especially when using a multi-threaded download client, however μtorrent still maintains about a 30kB/s upload speed.
                                                              I'm open to both chastisement for being dim, and suggestions as to a solution if I'm not
                                                              What have I missed?!?

                                                              1 Reply Last reply Reply Quote 0
                                                              • B
                                                                Borage last edited by

                                                                @The:

                                                                Any more ideas on this one?

                                                                Many commercial router vendors said that it's impossible to bandwidth limit encrypted P2P traffic. Only one router vendor claims that they can limit encrypted Bittorrent & Obfuscated eMule traffic (don't remember the company name). I've been using MikroTik RouterOS from the beginning, and since some P2P clients implemented encryption, it's now only possible to block the encrypted traffic. I asked the MikroTik vendor and they said that it's impossible to bandwidth limit encrypted P2P traffic.

                                                                This problem forced me to add rules for all normal traffic, and one for the rest (unknown traffic).

                                                                1 Reply Last reply Reply Quote 0
                                                                • First post
                                                                  Last post