Re: tc nexthdr

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxx>:
>> 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: signature.asc
Description: Message signed with OpenPGP using GPGMail


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux