skype for ios/droid not filtered in l7

Discussion in 'Tomato Firmware' started by pektong, Mar 5, 2013.

  1. pektong

    pektong Networkin' Nut Member

    I just noticed that my skype session in my droid tablet was not captured by skype rule and was classified as bulk. What should I do to classify it as voip?
  2. Frequenzy

    Frequenzy Networkin' Nut Member

    can you not classify by defining the ports that skype is using.
  3. philess

    philess Networkin' Nut Member

    It is *almost* impossible to fully classify Skype for QoS. Skype dynamically opens a whole lot of random
    ports in addition a fixed one and switches between different nodes for better performance.

    What i did is in the Skype clients (Windows & Mac), set Skype to use a fixed port (eg. 50111) and
    then set your QoS to prioritize that port, in addition to common standard Skype ports (2062,5521,7007,23399).
    This will classify *most* of Skype connections, but you will always still see some random ones popping up.
    As far as i know, there is no real solution to this. Also, no real way to set a fixed port for the iOS client anyway...
  4. Monk E. Boy

    Monk E. Boy Network Guru Member

    The only sure-fire way to classify Skype traffic is to assign a fixed DHCP lease for a device, have all your rules up top classifying all your normal traffic, then as the last two QoS rules classify traffic to & from that lease to your Skype-friendly QoS category. Skype's refusal to allow for easy categorization of traffic is the biggest reason I honestly don't give two craps about whether Skype works or not. Half the time it seemed like Skype didn't know how their clients interacted, and I can't imagine Microsoft is going to make this problem better... but who knows.
  5. koitsu

    koitsu Network Guru Member

    So, who here has actually taken the time to look at the network I/O using tcpdump and/or Wireshark, between a Skype client and the Internet (when launching Skype)? I haven't seen any evidence of this being done anywhere.

    The thread is about layer 7 filtering rules. Layer 7. When I see people talking of port numbers, that isn't L7 filtering -- that's layer 4 filtering, or at least a form of filtering that's based on layer 4. The entire point of L7 filtering is to look at the payload (data/content) of the packet and, when combined with lots of criteria, block packets for an application regardless of what port number it's using. The tricky part is ruleset generation; too vague of rules and you could block non-Skype traffic, while "excessive" rules (i.e. crappy regexes like these) can result in high CPU load and affect throughput for all traffic.

    I do use Skype, but I do not use any form of L7 filtering or QoS on my network. If someone wants me to do analysis of the packets, ask and be patient (this can take me a very, very long time, as I have to have lots of sample data).
  6. Monk E. Boy

    Monk E. Boy Network Guru Member

    Sorry, I always assume people are aware that Tomato's L7 Skype filter doesn't work properly. I suspect at one time it did work but Skype was subsequently updated, but maybe it never caught all the traffic.

    I know with Skype picking ports somewhat at random a layer 4 approach won't work, which is why I recommended the (extremely inelegant) "all traffic" approach. Let all the other rules whack off all the easily categorized traffic and let this rule catch whatever traffic remains to the Skype'd device and prioritize it so Skype won't get demolished.
  7. Porter

    Porter LI Guru Member

    I do appreciate your enthusiasm! :) I'm by no means a pro when it comes to regexes, but I somehow managed to write the new youtube-filter. I wrote down some useful tips for testing new patterns here:

    Btw there is a mistake in the post, the slow pattern looks like this: (GET \/videoplayback\?|GET \/crossdomain\.xml). The difference looks small but it isn't. The library is known to behave erratic.

    The pattern files contain some comments about how the protocols work and where to get more information:

    Good luck!
  8. Toastman

    Toastman Super Moderator Staff Member Member

    Porter, in that post, maybe the forum software has changed the lines, but both look the same to me. Just wanted to check I entered the right code into my change :) I can't remember now if we discussed that before.

    GET (\/videoplayback\?|\/crossdomain\.xml)
  9. Porter

    Porter LI Guru Member

    They look the same because I somehow made a mistake. Since I'm not allowed to edit posts after 30min, this never got fixed. I'll probably run those benchmarks again just to make sure I actually used the fast pattern.
  10. Toastman

    Toastman Super Moderator Staff Member Member

    I can edit them for posterity ... if u let me know what to do. At the moment, I can't seem to post PM's though.
  11. Porter

    Porter LI Guru Member


    Ok, checked again: everything is ok. My new filter contains the fast pattern.

    The first pattern in the comparison needs to look like this: (GET \/videoplayback\?|GET \/crossdomain\.xml)

    Thank you!
  12. Toastman

    Toastman Super Moderator Staff Member Member

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice