tc nexthdr

tc nexthdr

[Christian Rößner]

Hi,

this is my first post to this list.

I try to match several RTPv2 codecs with tc u32 and I ended up with the following:

tc filter add dev mydevice protocol ip parent 1:0 pref 3 u32 \
    match ip protocol 0x11 0xFF \
    match u16 0x8008 0xC07F at 28 \
    flowid 1:110

So far this works. It means (at least I hope so):

- match UDP,
- match the first two bytes in the UDP payload, which are part of the RTP header
  - first two bits say „version 2“ RTP
  - last 7 bits encode the codec. In this example G.711 PCMA

So now this code is just working for IPv4. And I would like to have a more generic one using nexthdr. So I tried:

tc filter add dev mydevice protocol ip parent 1:0 pref 3 u32 \
    match ip protocol 0x11 0xFF \
    match u16 0x8008 0xC07F at nexthdr+4 \
    flowid 1:110

Problem with this is that it matches packets, but when doing a test call with VoIP I can see that it does not match RTP traffic but some wrong traffic. So I guess my „nexthdr+4“ is wrong. I thought that the nexthdr depends on the selector u16 and therefor needs to be 4. 4*16d, which should be 8 bytes offset to UDP, which is the beginning of the payload, isn’t it?

Can someone help me fixing this rule? Thanks in advance

Kind regards

-Christian Rößner

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: tc nexthdr

[Remy Mudingay]

Hi Christian,

Although the u32 filter is quite powerful it has a few limitations. I would not recommend matching VOIP which can use RTP, SIP, H323 etc. 
The issue you might be facing, in attempting to identify RTP, might be due to the first 2 payload bytes of an RTP packet typically begin with 0x8$$$ or 0x9$$$ ( where $ can be any hex value). This can erroneously also match DNS or other UDP traffic. It can be done if you also specify the packet length inorder to exclude DNS but  I would recommend going with a packet inspection library like nDPI (kernel module + iptables + tc filter fw).

Cheers,

Remy

Sent from my Phone

> On 10 Apr 2014, at 10:57, Christian Rößner <cr@sys4.de> wrote:
> 
> Hi,
> 
> this is my first post to this list.
> 
> I try to match several RTPv2 codecs with tc u32 and I ended up with the following:
> 
> tc filter add dev mydevice protocol ip parent 1:0 pref 3 u32 \
>    match ip protocol 0x11 0xFF \
>    match u16 0x8008 0xC07F at 28 \
>    flowid 1:110
> 
> So far this works. It means (at least I hope so):
> 
> - match UDP,
> - match the first two bytes in the UDP payload, which are part of the RTP header
>  - first two bits say „version 2“ RTP
>  - last 7 bits encode the codec. In this example G.711 PCMA
> 
> So now this code is just working for IPv4. And I would like to have a more generic one using nexthdr. So I tried:
> 
> tc filter add dev mydevice protocol ip parent 1:0 pref 3 u32 \
>    match ip protocol 0x11 0xFF \
>    match u16 0x8008 0xC07F at nexthdr+4 \
>    flowid 1:110
> 
> Problem with this is that it matches packets, but when doing a test call with VoIP I can see that it does not match RTP traffic but some wrong traffic. So I guess my „nexthdr+4“ is wrong. I thought that the nexthdr depends on the selector u16 and therefor needs to be 4. 4*16d, which should be 8 bytes offset to UDP, which is the beginning of the payload, isn’t it?
> 
> Can someone help me fixing this rule? Thanks in advance
> 
> Kind regards
> 
> -Christian Rößner
> 
> --
> [*] sys4 AG
> 
> http://sys4.de, +49 (89) 30 90 46 64
> Franziskanerstraße 15, 81669 München
> 
> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> Vorstand: Patrick Ben Koetter, Marc Schiffbauer
> Aufsichtsratsvorsitzender: Florian Kirstein
> 
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tc nexthdr

[Christian Rößner]

[-- Attachment #1: Type: text/plain, Size: 2350 bytes --]

Hi Remy,

> Although the u32 filter is quite powerful it has a few limitations. I would not recommend matching VOIP which can use RTP, SIP, H323 etc. 
> The issue you might be facing, in attempting to identify RTP, might be due to the first 2 payload bytes of an RTP packet typically begin with 0x8$$$ or 0x9$$$ ( where $ can be any hex value). This can erroneously also match DNS or other UDP traffic. It can be done if you also specify the packet length inorder to exclude DNS but  I would recommend going with a packet inspection library like nDPI (kernel module + iptables + tc filter fw).

thanks for your answer. I had thought about the false-positive rate and watched the u32 rule for round about 48h. 90% is matched correctly, which is quite acceptable for us, but…

Earlier I had used OpenDPI and I was happy with it. But because it was closed, I looked for another solution. I contacted hour well known SIP providers and let me give the IP networks they use for telephony. This works, but I always prefer a generic independent solution and therefor thought about a way of detecting SIP/RTP.

I first used the -m string match combined with packet length, UDP —sport 5000: and —dport 5000:, but I think string-match is expensive. So I deployed the u32 version.

I know that nDPI is a fork of he latest OpenDPI, but still I could not find a kernel module built with nDPI. Do you have a source for this?

If nDP would be useable, I would detect packets and mark them and afterwards using CONNMARK for the whole connection. That would be probably the best solution. So if you have further details on that, I really would appreciate it :)

Currently the u32 is nice. I asked our SIP providers today, if they can tell me, what codecs they use. It are:

G.729 - ~ 12 kbit/s
G.711 - ~ 100 kbit/s
GSM - ~ 13 - 20 kbit/s
G.726 - ~ 16 - 40 kbit/s

and they use SIP and have no plans to switch to H.323 or IAX.

So I could reduce u32 filters to these. But what would be the „right“ nexthdr+X setting behind the u16 selector?

Thanks in advance
 
-Christian Rößner

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: tc nexthdr

[Christian Rößner]

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

Hi,

Am 10.04.2014 um 13:01 schrieb Christian Rößner <cr@sys4.de>:

> If nDP would be useable, I would detect packets and mark them and afterwards using CONNMARK for the whole connection. That would be probably the best solution. So if you have further details on that, I really would appreciate it :)

I can not get nDPI compiled under Debian wheezy:

NDPI_PATH=/usr/local/src/DPI/nDPI make
if test -d ndpi_cpy; then \
                cp /usr/local/src/DPI/nDPI/src/* ndpi_cpy -R; \
        else \
                mkdir ndpi_cpy; \
                cp /usr/local/src/DPI/nDPI/src/* ndpi_cpy -R; \
        fi
make -C /lib/modules/3.2.0-4-amd64/build M=$PWD;
make[1]: Entering directory `/usr/src/linux-headers-3.2.0-4-amd64'
  CC [M]  /usr/local/src/DPI/ndpi-netfilter/src/main.o
/usr/local/src/DPI/ndpi-netfilter/src/main.c: In function ‘ndpi_mt_check’:
/usr/local/src/DPI/ndpi-netfilter/src/main.c:586:2: error: implicit declaration of function ‘NDPI_BITMASK_IS_ZERO’ [-Werror=implicit-function-declaration]
/usr/local/src/DPI/ndpi-netfilter/src/main.c: In function ‘ndpi_mt_init’:
/usr/local/src/DPI/ndpi-netfilter/src/main.c:681:54: warning: passing argument 3 of ‘ndpi_init_detection_module’ from incompatible pointer type [enabled by default]
/usr/local/src/DPI/ndpi-netfilter/src/ndpi_cpy/include/ndpi_public_functions.h:150:40: note: expected ‘void (*)(void *)’ but argument is of type ‘void (*)(u32,  void *, enum ndpi_log_level_t,  const char *)’
/usr/local/src/DPI/ndpi-netfilter/src/main.c:681:54: error: too few arguments to function ‘ndpi_init_detection_module’
/usr/local/src/DPI/ndpi-netfilter/src/ndpi_cpy/include/ndpi_public_functions.h:150:40: note: declared here
cc1: some warnings being treated as errors
make[4]: *** [/usr/local/src/DPI/ndpi-netfilter/src/main.o] Error 1
make[3]: *** [_module_/usr/local/src/DPI/ndpi-netfilter/src] Error 2
make[2]: *** [sub-make] Error 2
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-3.2.0-4-amd64'
make: *** [all] Error 2

Google does not help. So I stay with the u32 solution for now. Back to my main question: What should nexthdr+X look like to do the same as „at 28“?

Thanks in advance

-Christian Rößner

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: tc nexthdr

[Anton 'EvilMan' Danilov]

Hello Christian.

You are trying to use the offset. It's valid only after linking.

See http://ace-host.stuart.id.au/russell/files/tc/doc/cls_u32.txt for
details and examples.

2014-04-10 12:57 GMT+04:00 Christian Rößner <cr@sys4.de>:
> Hi,
>
> this is my first post to this list.
>
> I try to match several RTPv2 codecs with tc u32 and I ended up with the following:
>
> tc filter add dev mydevice protocol ip parent 1:0 pref 3 u32 \
>     match ip protocol 0x11 0xFF \
>     match u16 0x8008 0xC07F at 28 \
>     flowid 1:110
>
> So far this works. It means (at least I hope so):
>
> - match UDP,
> - match the first two bytes in the UDP payload, which are part of the RTP header
>   - first two bits say „version 2“ RTP
>   - last 7 bits encode the codec. In this example G.711 PCMA
>
> So now this code is just working for IPv4. And I would like to have a more generic one using nexthdr. So I tried:
>
> tc filter add dev mydevice protocol ip parent 1:0 pref 3 u32 \
>     match ip protocol 0x11 0xFF \
>     match u16 0x8008 0xC07F at nexthdr+4 \
>     flowid 1:110
>
> Problem with this is that it matches packets, but when doing a test call with VoIP I can see that it does not match RTP traffic but some wrong traffic. So I guess my „nexthdr+4“ is wrong. I thought that the nexthdr depends on the selector u16 and therefor needs to be 4. 4*16d, which should be 8 bytes offset to UDP, which is the beginning of the payload, isn’t it?
>
> Can someone help me fixing this rule? Thanks in advance
>
> Kind regards
>
> -Christian Rößner
>
> --
> [*] sys4 AG
>
> http://sys4.de, +49 (89) 30 90 46 64
> Franziskanerstraße 15, 81669 München
>
> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> Vorstand: Patrick Ben Koetter, Marc Schiffbauer
> Aufsichtsratsvorsitzender: Florian Kirstein
>
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Anton.

Re: tc nexthdr

[Christian Rößner]

[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]

Hi Anton,


> You are trying to use the offset. It's valid only after linking.
> 
> See http://ace-host.stuart.id.au/russell/files/tc/doc/cls_u32.txt for
> details and examples.

thank you for your reply :) And thanks for the link

Remy got nDPI kernel module compiled and I have included all this on our router. Seems to work so far.

Even nDPI is great, RDP detection needs some tweaks, as it covers all RDP codecs including video, which I did not want to match. I actually limit the length as well from minimum 20 up to 200 bytes.

I also could do the length test in u32, as I have this information in UDP. But some codecs have a dynamic PT, so I can not stay with u32 and need nDPI ;-)

Thanks for all your help

Christian

> 2014-04-10 12:57 GMT+04:00 Christian Rößner <cr@sys4.de>:
>> Hi,
>> 
>> this is my first post to this list.
>> 
>> I try to match several RTPv2 codecs with tc u32 and I ended up with the following:
>> 
>> tc filter add dev mydevice protocol ip parent 1:0 pref 3 u32 \
>>    match ip protocol 0x11 0xFF \
>>    match u16 0x8008 0xC07F at 28 \
>>    flowid 1:110
>> 
>> So far this works. It means (at least I hope so):
>> 
>> - match UDP,
>> - match the first two bytes in the UDP payload, which are part of the RTP header
>>  - first two bits say „version 2“ RTP
>>  - last 7 bits encode the codec. In this example G.711 PCMA
>> 
>> So now this code is just working for IPv4. And I would like to have a more generic one using nexthdr. So I tried:
>> 
>> tc filter add dev mydevice protocol ip parent 1:0 pref 3 u32 \
>>    match ip protocol 0x11 0xFF \
>>    match u16 0x8008 0xC07F at nexthdr+4 \
>>    flowid 1:110
>> 
>> Problem with this is that it matches packets, but when doing a test call with VoIP I can see that it does not match RTP traffic but some wrong traffic. So I guess my „nexthdr+4“ is wrong. I thought that the nexthdr depends on the selector u16 and therefor needs to be 4. 4*16=64, which should be 8 bytes offset to UDP, which is the beginning of the payload, isn’t it?
>> 
>> Can someone help me fixing this rule? Thanks in advance

-Christian Rößner

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]