1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

QoS inaccurate ?

Discussion in 'Tomato Firmware' started by der_Kief, Nov 18, 2006.

  1. der_Kief

    der_Kief Super Moderator Staff Member Member

    Hi @ all,

    since a few days i try to figure out whats the problem here. It seems that QoS is inaccurate in my case. When i do p2p most of the connections are marked as lowest by QoS but there are some connections from that p2p computer that are marked as unclassified but they have the ports (30000,30100,30101,30102) which i set up on the p2p computer.Regardless of setting IPP2P, L7, Port based rules or by IP. Here are some screenshots:

    [​IMG]

    [​IMG]

    [​IMG]

    I dont know what i'm doing wrong !? Maybe this has do to with my other problem
    Maybe someone has a idea or maybe a solution for this. THX

    der_Kief
     
  2. digitalgeek

    digitalgeek Network Guru Member

    QOS see's your "monitoring" activity as unclassified which sku's the graph
     
  3. der_Kief

    der_Kief Super Moderator Staff Member Member

    Yes i know, but the unclassified traffic on the screenshots is not the computer (ip) which monitors the router :wink:
    The source ports 30xxx are the ports i set up on my p2p machine. So something doesn't work as it should.
     
  4. GeeTek

    GeeTek Guest

    I think the connections are unclassified when they transition from one class to another as in when you change classes. Also, it seems that they are designated as unclassified when they are first opened. I think there is a snag somewhere that keeps these temporarily unclassified connections open even after they have closed. Try shutting down the P2P application and dis-connect the cable or power down the computer. I have had the router hold open connections for 30 or 45 minutes sometimes after the computer was disconnected / shut down. A lot of connections stayed open for 5 or 10 minutes until I shortened down the TCP timings. Then the update response time got much better. I do not know the correct way to tune the TCP/IP timings for torrent operation.
     
  5. der_Kief

    der_Kief Super Moderator Staff Member Member

    Maybe someone who has experience with TCP/IP timings can suggest optimized settings for p2p ? Here is a screeny of my conntrack/netfilter settings:

    [​IMG]

    der_Kief
     
  6. maxzerker

    maxzerker LI Guru Member

    L7 Filter for p2p is not that 100% accurate
    Especially bittorrent, they have althernate pattern (Encryption)
    That why QoS can't classify those packets to the right class.
     
  7. der_Kief

    der_Kief Super Moderator Staff Member Member

    But when i set this computer by IP to the lowest class it should not matter which application is accessing the internet. This way QoS should work !

    der_Kief
     
  8. kendawg

    kendawg LI Guru Member

    you're right der_Kief, it should be working with those settings....I don't know how to help you though
     
  9. RTSAnime

    RTSAnime Network Guru Member

    Filter based upon ports. IE my bittorrent client always uses local port x so therefore all traffic on local port x is set to lowest priority
     
  10. robsonn

    robsonn Network Guru Member

    There are some minor problems with classifying per IP or it's just inaccurate.
    When you set identical rule but with MAC classification instead of IP then this will work very fast and precisesly. Just avoid using IP, prioritize pc's and/or voip boxes through MAC.
    Maybe there is some problem that Jon fixed and will be released in new version. When it will be out we will know.
     
  11. der_Kief

    der_Kief Super Moderator Staff Member Member

    I tried that but it seems not to be the solution. Its better than before but there are still some connections in unclassified (mostly UDP packets) :frown:

    der_Kief
     
  12. digitalgeek

    digitalgeek Network Guru Member

    filtering by IP (local) is a bad idea... if the lease renews on your box and the IP's shuffle the entire QOS list becomes invalid your best bet is to filter by MAC or port... these are static and never fail... I would also avoid L7 protocols as bittorent with encription is not supposed to look like bittorrent, otherwise there would no point in using the encription... the sure way to catch your activity every time as I said is mac or port
     
  13. der_Kief

    der_Kief Super Moderator Staff Member Member

    At the moment i'm only filtering by MAC (as robsonn mentioned) and in my case it doesn't help ! Trust me, i think i tried any combination there is :wink:
    Either i'm stupid :biggrin: or something is wrong with my setup/hardware or the firmware is faulty.

    der_Kief
     
  14. BeHappy

    BeHappy Network Guru Member

    It may sound ridiculous, but when using the tool from this site
    http://www.hyperwrt.org/forum/viewtopic.php?id=2002&p=3 on Tomato the Qos in my case is sharped more accurate than I've expected from Tomato.

    My setup
    - Not use Inbound Layer7
    - Qos Strict Rule Order - Yes -
    - Qos Default Class - Highest -
    Parts from script pasted to Firewall Setup
    #Added variables to optimize script
    TCA="tc class add dev br0"
    TQA="tc qdisc add dev br0"
    SFQ="sfq perturb 10"
    #Deleting root qdisc
    tc qdisc del dev br0 root
    #Creating new root qdisc
    tc qdisc add dev br0 root handle 1: htb
    #Added SFQ strategy (only for Tomato)
    $TQA parent 1:10 handle 10: $SFQ
    #Creating ingress qdisc for upload
    tc qdisc add dev br0 ingress
     
  15. rcordorica

    rcordorica Network Guru Member

    I am having the same problem on my WRT54GL 1.1.

    Even though I have QOS rules for bittorrent traffic (Azuereus with UPnP port forwarding) set to the lowest classification and also my default priority is "lowest" too.

    Even when I try to force the lowest QOS based on MAC address or the port (because 99% of the unclassified connections are from a single bittorrent port), the same amount of connections go "unclassified".

    I guess it wouldn't be a problem if unclassified connections are treated as my default priority, but then why wouldn't they show up in the Lowest category? Is this intended behavior? if not, then what priority do "unclassified" connections have?

    Here are screenshots from tomato 1.0. THis is not some kind of temporary unclassified connection issue because I have had these QOS settings for at least a day now, but continuously new "unclassified" connections are made.

    [​IMG]
    [​IMG]
     
  16. der_Kief

    der_Kief Super Moderator Staff Member Member

    Hi,
    this is what Jon mentioned:
    so dont worry about it.

    der_Kief
     
  17. GeeTek

    GeeTek Guest

    So Yah, like, don't worry too much about them. I thought that they were there until they got classsified, which might take a few clocks. On a big torrent session, this could make the unclassifieds go up pretty high. Just an idea. After shortening a lot of the TCP timeout values to half, the QOS readings seemed to respond better on my rig. You might also check out the TCP connection count limit script. It really helps a lot.
     
  18. canis

    canis Network Guru Member

    Hey Guys, nice to meet back from other forums, but there it was messy to follow the advises.
    Since I`m using the Thomson Ping Responder, the unneccessary pings are answerded by the main router and not entering the subnets, only requested pings are going through to the requesting client.
    Since this, there is no failing classification any more.
     
  19. der_Kief

    der_Kief Super Moderator Staff Member Member

    Hi @ All,

    i found the solution for that thing ! Since i changed from port forwarding to port triggering the "problem" with unclassified p2p connections is gone (in my case). So for everybody with this issue try port triggering.

    der_Kief
     
  20. lazx888

    lazx888 Network Guru Member

    Having a problem with L7 "skypetoskype" and "skypeout" rules... Skype should be put into "class a"... it is the top rule of my qos rules. The weird thing is that some torrent connections are being lumped into the skype rules (torrents != skype!!). Can anyone explain this?

    My torrent (L7) rule seems to catch most of the torrent connections.
     
  21. dvaskelis

    dvaskelis Network Guru Member

    Prioritizing Skype on Tomato

    See this post for an explanation. The bottom line:
     
  22. lazx888

    lazx888 Network Guru Member

    thanks :)

    didn't know L7 is unreliable... or well, L7 for skype is unreliable.
     
  23. GeeTek

    GeeTek Guest

    Try putting the torrent catching rule ABOVE the skype rule and use "Strict rule order". Send the torrent traffic to a class category other than "A" .
     
  24. dvaskelis

    dvaskelis Network Guru Member

    Flagging BitTorrent traffic in Tomato

    You'll find that encrypted BitTorrent traffic is "invisible" to l7-filter and ipp2p, that's sort of the point of crypto in Azureus or encryption in µTorrent. Also, unless you explicitly configured your client to turn away encrypted requests, Azureus and µTorrent will accept encrypted connections even if you have set your BitTorrent client to have encryption turned off. And, there's no one-way protocol encryption, so such connections are encrypted in both directions!

    You can also flag BitTorrent traffic by ports, but not by your incoming port alone, as you can't really flag all BitTorrent traffic because there are so many ports that are used by the other connections. This is because your set BitTorrent port is not going to be the only port BitTorrent traffic uses for transferring data. The port in the client is the incoming "listening" port, while outgoing connections will use a random local port just like every other TCP/IP application. See the µTorrent FAQ for more details. Also, you also don't control the ports that other connected BitTorrent clients are using for their incoming connections. You can flag a large range, like 1024-65535, but that will likely also flag other unintended traffic too. I use a slightly less expansive port range: 6880-6999 and 49152-65534. The first is a slightly wide "old" BitTorrent port range, and the second is the current "recommended" BitTorrent port range. I combine this with l7-filter and ipp2p and that seems to strike the best balance in flagging almost all real BitTorrent traffic.
     

Share This Page