On 27 aug 2012, at 18:56, Guy Harris wrote:
> On Aug 27, 2012, at 5:11 AM, Aktuna, Ilker, Vodafone Turkey wrote:
>
>> Now, my problem is about tcpdump getting only one way traffic if used with a filter. On the server that I use tcpdump, there is libpcap 0.9.4 and tcpdump 3.9.4.
>> Normally if I take captures without filter, I can receive 2 way SIP traffic. However, if I put a capture filter like “port 5060” , I can only receive one way traffic in the file created.
>>
>> In fact, I know why this happens; the SIP traffic is tunneled with ip protocol 4 (ipip) in one way. So, if I put a filter “port 5060” that doesn’t cover “udp packets under ip protocol 4”. How can I solve this issue ?
>
> By changing the libpcap source code to add an "ipip" term, similar to the "vlan", "mpls", and "pppoes" terms, to
>
> 1) check for IP protocol 4
>
> and
>
> 2) change the offsets used when checking fields in transport-layer headers
>
> building that version of libpcap and linking tcpdump (and other programs you want to support IP-in-IP in capture filters) with that version of libpcap, and capture using "port 5060 and (ipip and port 5060).
This would of course be the best (longterm) solution and the most flexible. However, it won't help you today :-(
You can use offsets into the IP layer to do the checking yourself, but the capture filter will get ugly if you want to incorporate every possible packet.
The simple version which might work for you would be:
"port 5060 or (ip proto 4 and ip[20+9]=17 and (ip[20+20+0:2]=5060 or ip[20+20+2:2]=5060))"
ip[20+0] will point to the inner IP layer (offset 20) at offset 9, which is the IP protocol in the inner IP header
ip[20+20+0:2] will point the the first two bytes of the udp header (after the two IP layers), this is the source port
ip[20+20+2:2] will point the the first two bytes of the udp header (after the two IP layers), this is de destination port
This works only for SIP packets over UDP over IPv4 where there are no IP options in either IP header in the packet. To add TCP would make it:
"port 5060 or (ip proto 4 and (ip[20+9]=17 or ip[20+9]=6) and (ip[20+20+0:2]=5060 or ip[20+20+2:2]=5060))"
Then if you want to be able to handle packets with IP options in the inner IP layer it will become:
"port 5060 or (ip proto 4 and (ip[20+9]=17 or ip[20+9]=6) and (ip[20+((ip[20]&0x0f)<<2)+0:2]=5060 or ip[20+((ip[20]&0x0f)<<2)+2:2]=5060))"
((ip[20]&0x0f)<<2) calculates the IP header length of the inner IP layer (assuming the outer IP layer has an IP header length of 20)
And then adding the handling of IP options in the outer IP layer would make it:
"port 5060 or (ip proto 4 and (ip[((ip[0]&0x0f)<<2)+9]=17 or ip[((ip[0]&0x0f)<<2)+9]=6) and (ip[((ip[0]&0x0f)<<2)+((ip[((ip[0]&0x0f)<<2)]&0x0f)<<2)+0:2]=5060 or ip[((ip[0]&0x0f)<<2)+((ip[((ip[0]&0x0f)<<2)]&0x0f)<<2)+2:2]=5060))"
((ip[((ip[0]&0x0f)<<2)]&0x0f)<<2) calculates the IP header length of the inner IP layer
Adding IPv6 support will double the complexity :-)
So indeed, to make life fun, the ipip term should be added to libpcap, but for now, you should at least be able to capture your SIP packets...
Cheers,
Sake
DISCLAIMER: The above filter was not tested against real traffic, so I might have made a little mistake, please supply an unfiltered trace file if it does not work for you and I will see if I can correct the filter :-)
