custom l7 *.pat file creation

Discussion in 'Sveasoft Firmware' started by precursor, Apr 29, 2005.

  1. precursor

    precursor Network Guru Member

    Hi there,

    I picked up a WRT54G 3.0 yesterday after I wrote an ask slashdot on bandwidth sharing, and a lot of users recommended it.

    I got the pre7 version of alchemy running on my router just fine (after the thing was shipped to me bricked).

    After hearing so much great stuff on how easy the QoS was to setup on alchemy, I was very sad to see that the Counter-Strike filter is quite old, and does not work with newer versions. After some research today (which I should have done before hand) I found that alchemy does its QoS based on the linux l7 project (which is very cool). Now, I think this is an excellent way to trigger QoS, but the default rules just don't work.

    I went ahead and captured some packets from both Counter-Strike: Source and Counter-Strike 1.6 (as both protocols are similar) with ethereal. My problem is that I have no idea how to write, or test the regular expression to match on these packets. I was hoping that if I posted the packet dumps, somone could help me put it together, or point me in the right direction.

    CS: Source

    0000 00 11 09 2a a8 79 00 13 10 2c 3f d7 08 00 45 20 ...*.y...,?...E
    0010 00 72 b9 f6 00 00 6b 11 b6 78 18 0e 04 cc c0 a8 .r....k..x......
    0020 01 6a 69 87 04 65 00 5e 01 ac ff ff ff ff 49 07 .ji..e.^......I.
    0030 54 4a 27 73 20 50 6c 61 63 65 20 6f 66 20 50 61 TJ's Place of Pa
    0040 69 6e 00 64 65 5f 70 69 72 61 6e 65 73 69 00 63 in.de_piranesi.c
    0050 73 74 72 69 6b 65 00 43 6f 75 6e 74 65 72 2d 53 strike.Counter-S
    0060 74 72 69 6b 65 3a 20 53 6f 75 72 63 65 00 dc 00 trike: Source...
    0070 08 10 06 64 77 00 00 31 2e 30 2e 30 2e 31 38 00 ...dw..

    CS 1.6

    0000 00 11 09 2a a8 79 00 13 10 2c 3f d7 08 00 45 20 ...*.y...,?...E
    0010 00 a7 31 1d 00 00 6a 11 4b cb 18 0c f9 25 c0 a8 ..1...j.K....%..
    0020 01 64 69 87 04 29 00 93 a3 af ff ff ff ff 6d 32 .di..)........m2
    0030 34 2e 31 32 2e 32 34 39 2e 33 37 3a 32 37 30 31
    0040 35 00 32 34 2f 37 20 7b 46 46 57 7d 20 50 75 62 5.24/7 {FFW} Pub
    0050 6c 69 63 20 43 6c 61 6e 20 53 65 72 76 65 72 20 lic Clan Server
    0060 2d 20 32 30 30 35 20 2d 00 64 65 5f 64 75 73 74 - 2005 -.de_dust
    0070 32 00 63 73 74 72 69 6b 65 00 43 6f 75 6e 74 65 2.cstrike.Counte
    0080 72 2d 53 74 72 69 6b 65 00 06 18 2f 64 77 00 01 r-Strike.../dw..
    0090 77 77 77 2e 63 6f 75 6e 74 65 72 2d 73 74 72 69 www.counter-stri
    00a0 6b 65 2e 6e 65 74 00 00 00 01 00 00 00 00 9e f7
    00b0 0a 00 01 01 00

    From what I can tell, both versions have the following text in common:


    Any help would be appreciated!

  2. RAST

    RAST Network Guru Member

    You're on the right path. You can easily edit the counterstrike.pat to use your string match instead. That's easy.

    The hard part is getting that definition to work on the WRT. There is a good thread on this over at sveasoft's forum. Do a search on "L7" and your first match will be on a thread that describes just how to do this. I reallyreally wish the would add a good way to import new L7 definitions without all the contortions.
  3. Disman_ca

    Disman_ca Super Moderator Staff Member Member

  4. _Shorty

    _Shorty Network Guru Member

    hmm, have to be a subscriber to see the thread in question perhaps? Nothing related to this shows up in a search I just did, and I'm not subscribed. Only returned four threads, none of which concerned adding/editing the L7 stuff.

  5. _Shorty

    _Shorty Network Guru Member

    hmm. Perhaps the filter isn't working because it's looking for and it appears that your second packet contains but not, so perhaps valve removed the dl. portion from those packets sometime ago. Do you still have the CS Source packet data? It ends before the 1.6 packet you've shown does, so I'm just wondering if it contains the same string sans-"dl." that the 1.6 packet does. Wonder how easy it'll be to change this on the router, wish I could see the thread in question on sveasoft's site.
  6. _Shorty

    _Shorty Network Guru Member

  7. _Shorty

    _Shorty Network Guru Member

    ok, I've got myself a custom pattern named cstrike now that is apparently working for current versions of counter-strike/counter-strike source. Now I just need to figure out what to 'mark' them as so that the QoS engine does what I want it to when it encounters those packets. I've got this in my rc_startup script
    echo -e cstrike\\n.cstrike.Counter-Strike >/tmp/cstrike.pat
    which creates the cstrike pattern in /tmp/cstrike.pat, and now I just need to find out what to mark them as. There are four different QoS levels, so I would guess that they probably get marked as 1, 2, 3, or 4 depending on which level you want. But that's what I need to find out, which integers are used to mark for which QoS levels? Once I know that I can use a command like this to call it from rc_firewall
    iptables -t mangle -A POSTROUTING -m layer7 --l7dir /tmp --l7proto cstrike -j MARK --set-mark 3
    edit - hmm, perhaps this could be divined from the dd-wrt source code.
  8. Disman_ca

    Disman_ca Super Moderator Staff Member Member

    Premium = 10
    Express = 20
    Standard = 30
    Bulk = 40
  9. _Shorty

    _Shorty Network Guru Member

    awesome, thanks! :)
  10. _Shorty

    _Shorty Network Guru Member

    well, not sure what the difference is, but it seems to work fairly well with bittorrent and CSS, but not G2 and CSS. Perhaps the gnutella pattern isn't matching G2, or perhaps it's just some other factor(s) but it didn't work as well as it did with bittorrent traffic. With a bittorrent download going at around 100KB/s I was getting a latency reading of about 60 in CSS and it was still fairly playable. And with a G2 download going at around 100KB/s I was getting a latency reading of about 350-400 in CSS and it was jerky and warping like mad. I don't know if it is the L7 pattern not matching G2 traffic, or if it's just something else. The pattern file's comments indicate it should catch G2 as well as G1 traffic, but who knows what it's doing in practice.
  11. precursor

    precursor Network Guru Member

    Hey Shorty,

    Just a quick note about that cstike.pat file..

    It needs to be edited a bit.

    The pattern line needs to be changed to:


    I had periods in there before, that were incorrect as they were actually null bytes, and not periods.

  12. _Shorty

    _Shorty Network Guru Member

    ah, didn't even notice that. Yeah, that might explain the slightly better, but not quite as good as you'd think, performance then. I guess the CS packets were only receiving standard priority. I'll change the pattern and try again after I get some food in me. Just got home. Thanks for the heads up!
  13. _Shorty

    _Shorty Network Guru Member

    well, still the same problem with gnutella2, so perhaps the gnutella pattern needs some work.
  14. _Shorty

    _Shorty Network Guru Member

    yay, got it working with gnutella2 downloads. I guess the gnutella.pat pattern is too specific for it to match gnutella2, or at least gnutella2 downloads anyway. I got it working with this pattern:
    ^gnutella[\x09-\x0d -~]*content-type: application/x-gnutella
    edit - I also notice that both CS and CSS packets you listed begin with "00 11 09 2a a8 79 00 13 10 2c 3f d7 08 00 45 20" and was wondering if that might also be used to make a more specific pattern for L7. Not sure what they mean, I think I'm going to ask Alfred from Valve on the HLDS mailing list and see if he can be of any assistance in making a more specific L7 pattern. Never know. ;)
  15. _Shorty

    _Shorty Network Guru Member

    fyi, the L7 project guys have updated their patterns with the CS/CSS change and the gnutella/gnutella2 addition. (among other changes, I believe)
  16. precursor

    precursor Network Guru Member

    GJ Shorty! =)

    We're both famous now lol
  17. _Shorty

    _Shorty Network Guru Member

  18. _Shorty

    _Shorty Network Guru Member

    well, here are the final patterns I ended up with. The CSS one just adds a bit onto the beginning, which should speed up its processing and definitely will get much less, if any, false positives. And the gnutella2 one from before I'm pretty sure wasn't working properly at all, but this one does.

    ~ # cat /tmp/cstrike.pat
    ~ # cat /tmp/gnutella2.pat

    edit - oh, and the code I use in rc_startup to create them (the CSS one is a bit tricky)

    echo -e cstrike\\n'^\\xff\\xff\\xff\\xff.*cstrikeCounter-Strike' >/tmp/cstrike.pat
    echo -e gnutella2\\n^gnutella.*application/x-gnutella >/tmp/gnutella2.pat
    And still the same rc_firewall code
    iptables -t mangle -A POSTROUTING -m layer7 --l7dir /tmp --l7proto cstrike -j MARK --set-mark 10
    iptables -t mangle -A POSTROUTING -m layer7 --l7dir /tmp --l7proto gnutella2 -j MARK --set-mark 40
  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