This is a static archive of our old Q&A Site. Please post any new questions and answers at

Capture filter bug? - SIP “udp port 5060” is not working with IP-IP-Encapsulation RFC2003


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

hrex's gravatar image

accept rate: 0%

2 Answers:


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:

(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 12
(002) ldb      [23]
(003) jeq      #0x11            jt 4    jf 12
(004) ldh      [20]
(005) jset     #0x1fff          jt 12   jf 6
(006) ldxb     4*([14]&0xf)
(007) ldh      [x + 14]
(008) jeq      #0x13c4          jt 11   jf 9
(009) ldh      [x + 16]
(010) jeq      #0x13c4          jt 11   jf 12
(011) ret      #65535
(012) ret      #0

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:

ip[<offset>:2]==0x13c4 or ip[<offset+2>:2==0x13c4

Could you upload a small example capture file on and post the link here, then we can assist you in building a proper capture filter.

answered 09 May '12, 05:42

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%


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%20Knochner's gravatar image

Kurt Knochner ♦
accept rate: 15%

edited 09 May '12, 03:13

1-3 is OK. It is UDP, 5060 and not encrypted. I can see it if I don't want to use capture filter or I using "host x.y.z.v"

There are some machines like this SBC which can mirror traffic to specified IP destination. Normally that machine is not in the SIP flow. To do this they are using RFC2003 IP-IP Encapsulation within IP.

So for example capture filter: "udp port 53" is working fine. "udp port 5060" is not working when packets arriving in RFC2003 IP-IP tunneling. I think because packets build up from L2-L3-L3-L4 headers.

(09 May '12, 03:19) hrex
(09 May '12, 05:35) Kurt Knochner ♦