I have an Session Border Controller which can use IP-in-IP encapsulation (RFC 2003) to send all sip data for example to a capture machine.
On that machine I have a wireshark to make SIP traces. It seems capture filter "udp port 5060" is not working. Could it cause by IP-IP encapsulation?
These packets contians the following headers: -Ethernet -IP -IP -UDP -SIP
Is this a bug? I tried 1.6.5 and 1.6.7 too.
asked 09 May '12, 01:54
Yes, the IP-in-IP encapsulation is messing up your capture filter. BPF (the engine responsible for filtering) uses fixed offsets to look for things. You can see the way the filter works by using "tcpdump -d <filter>". When I do this for "udp port 5060", I get:
As BPF is not aware of IP-in-IP encapsulation, it will check for the value of 5060 (0x13c4) in the wrong place. This also happens when there is vlan tagging, but for vlan tagging, you can add the word "vlan" to your filter to make it correct the offsets. I don't think there is a similar keyword for IP-in-IP.
You can manually account for variable IP header lengths or you can make life easy and test for specific offsets (counting from 0 from the start of the outer IP header) by using:
Could you upload a small example capture file on www.cloudshark.org and post the link here, then we can assist you in building a proper capture filter.
answered 09 May '12, 05:42
1.) SIP is defined for UDP and TCP 5060. Maybe the clients use TCP in your case.
2.) Maybe they use SIP on a non-standard port
3.) Maybe SIP is encrypted, then it's port 5061
4.) Regarding IP-IP encapsulation, you need to give us a little bit more information (e.g. how do you send the data to a capture machine).
I suggest to check 1. - 3. first.
EDIT: If your sniffer really sees IP-in-IP packets, the answer of the following question might help you:
answered 09 May '12, 02:15
Kurt Knochner ♦
edited 09 May '12, 03:13