SIP TCP decoding regression from Wireshark 1.99.0 to 3.6.8
Summary
Ever since Wireshark 1.99.0 was released, Wireshark no longer decodes certain TCP SIP messages. It may be caused by TCP segmentation and reassembly issues for SIP packets.
Steps to reproduce
I am supplying two example packet capture files. I saved them as regular non-ng pcap so that you can load them in any version of Wireshark. Load these packet captures into Wireshark 1.12.13 or earlier. Also load them into Wireshark 1.99.0 or later. View and compare the results and see what Wireshark could or could not decode as SIP messages. More details in sections below.
The default TCP Preferences are set, namely:
- Allow subdissector to reassemble TCP streams = yes
- Analyze TCP sequence numbers = yes
- Relative sequence numbers = yes
- Try heuristic sub-dissectors first = no
- Reassemble out-of-order segments = no (Not available in earlier versions, but the TCP segments are in order in my captures anyway.)
Note, I have played with these settings, and they have little to no effect, and changing these settings certainly does not resolve the issue which will be described below. And in any case, I will demonstrate how Wireshark 1.12.13 and earlier works correctly without touching these settings.
Example 1
Load the attached packet capture "Example1.pcap" into Wireshark 1.12.13 or earlier and into Wireshark 1.99.0 or later. The example packet numbers of interest are 611, 613, and 617. The TCP payload of the packets of interest are as follows. I show them here so that you can see the interesting TCP re-transmission and the interesting way SIP TCP puts two SIP Methods into one SIP TCP segment, and the second segment finishes the second SIP Method contents. I assume all this is legal because the SIP applications on both ends of the communication handle the SIP NOTIFY and SIP INVITE Dialogs without issue.Packet 611
**NOTIFY** sip:hcv-cb145826-35-5015@192.168.134.168:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.134.51:5060;branch=z9hG4bK38f69b31-23b0-4bce-9edbe45177c43e76
From: <sip:5003@463c1preferred.justanotherlab.com>;tag=497c610b-a61c-4663-ab4ec46149f29b5d
To: <sip:5015@example.com>;tag=75a8f910b7
Call-ID: aef1b6fcfbefa34e@10.9.8.110:5060
Content-Type: application/xpidf+xml
Content-Length: 404
Subscription-State: active;expires=3336
Event: presence
Contact: <sip:5003@192.168.134.51;transport=tcp>
CSeq: 7 NOTIFY
User-Agent: Sphericall/10.1.0 Build/648
Max-Forwards: 70
<?xml version="1.0"?>
<!DOCTYPE presence PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">
<presence>
<presentity uri="sip:5003@463c1preferred.justanotherlab.com;method=SUBSCRIBE" />
<display name="" />
<atom id="5003">
<address uri="sip:192.168.134.51:5060;user=ip" priority="0.800000">
<status status="inuse" />
<msnsubstatus substatus="onthephone" />
</address>
</atom>
</presence>
Packet 613
**NOTIFY** sip:hcv-cb145826-35-5015@192.168.134.168:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.134.51:5060;branch=z9hG4bK38f69b31-23b0-4bce-9edbe45177c43e76
From: <sip:5003@463c1preferred.justanotherlab.com>;tag=497c610b-a61c-4663-ab4ec46149f29b5d
To: <sip:5015@example.com>;tag=75a8f910b7
Call-ID: aef1b6fcfbefa34e@10.9.8.110:5060
Content-Type: application/xpidf+xml
Content-Length: 404
Subscription-State: active;expires=3336
Event: presence
Contact: <sip:5003@192.168.134.51;transport=tcp>
CSeq: 7 NOTIFY
User-Agent: Sphericall/10.1.0 Build/648
Max-Forwards: 70
<?xml version="1.0"?>
<!DOCTYPE presence PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">
<presence>
<presentity uri="sip:5003@463c1preferred.justanotherlab.com;method=SUBSCRIBE" />
<display name="" />
<atom id="5003">
<address uri="sip:192.168.134.51:5060;user=ip" priority="0.800000">
<status status="inuse" />
<msnsubstatus substatus="onthephone" />
</address>
</atom>
</presence>
**INVITE** sip:hcv-cb145826-35-5071@192.168.134.168:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.134.51:5060;branch=z9hG4bK7771b908-923a-4ddf-9ca929a6d5cfa06a
To: <sip:5071@example.com>
From: "Djokovic, Novak" <sip:5003@example.com>;tag=82b483ce-c4ca-4029-b3b9f169808e2b7b
Contact: "Djokovic, Novak" <sip:5003@192.168.134.51;transport=tcp>
P-Asserted-Identity: "Djokovic, Novak" <sip:5003@example.com>
Allow: INVITE,ACK,CANCEL,OPTIONS,REFER,BYE,REGISTER,SUBSCRIBE,NOTIFY,UPDATE,PRACK,MESSAG
Packet 617
E,INFO
Accept: application/sdp
Call-Info: <sip:192.168.134.51>;sphere-call-id=83892183
Content-Type: application/sdp
Content-Length: 320
Alert-Info: <internal-ring>
Supported: timer
Session-Expires: 120
Min-SE: 90
CSeq: 1662757364 INVITE
User-Agent: Sphericall/10.1.0 Build/648
Max-Forwards: 70
Call-ID: 5e021c85-6558-4921-ac59156dd49d0625@192.168.134.51
v=0
o=sphericall 495 496 IN IP4 192.168.134.51
s=-
c=IN IP4 192.168.134.103
t=0 0
m=audio 30000 RTP/AVP 0 96 97 101
a=ptime:20
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G7221/16000
a=fmtp:96 bitrate=24000
a=rtpmap:97 G7221/16000
a=fmtp:97 bitrate=32000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Example 2
This one is a bit different in that the dividing line for the regression is 1.99.2. Load the attached packet capture "Example2.pcap" into Wireshark 1.99.1 or earlier and into Wireshark 1.99.2 or later. The example packet numbers of interest are 1 and 8. I see no reason that 1.99.2 should reassemble frames 1 and 8. Yet Wireshark 1.99.2 through 4.0.0 does, and so frame 8's SIP message is not decoded.What is the current bug behavior?
Example 1
In Wireshark 1.99.0 the packets are decoded as follows, and it is the same view even in today's 3.6.8. If I were to filter on a SIP dialog, I would be wondering, "Hey, where did that SIP 100 Trying come from out of the blue? I don't see any INVITE packet." That is exactly what happened to me, until I expanded my filter to include any TCP 5060 packets and could see the segmentation and how Wireshark didn't show me a SIP INVITE message.
Also, this means that Wireshark 1.99+ is unable to show me the entire SIP flow of INVITE dialog, since it cannot show the first INVITE packet.
Example 2
In Wireshark 1.99.2 the packets are decoded as follows, and it is the same view even in today's 4.0.0. If I were to filter on a SIP dialog, I would be wondering, "Hey, where is the SIP 480 Temporarily Not Available packet I expected to see?" That is exactly what happened to me, until I expanded my filter to include any TCP 5060 packets and could see the unexpected reassembly and how Wireshark didn't show me this SIP 480 message.
What is the expected correct behavior?
Example 1
I expect Wireshark to be able to decode correctly as it did in 1.12.13 and before. Here is the same capture file in 1.12.13 where packets 613 and 617 are fully decoded and readable. It also looks the same in 0.99.6a.
and it even clearly explains how it was able to decode the INVITE message from TCP packets 613 and 617.
Example 2
I expect Wireshark to be able to decode correctly as it did in 1.99.1 and before. Here is the same capture file in 1.99.1 where packet 8 is decoded as SIP 480 correctly. It also looks the same in 0.99.6a.
Sample capture file
Relevant logs and/or screenshots
(Paste any relevant logs)
Build information
Works in 1.12.13 and earlier. Here is my 1.12.13
-------------------------------------------------------------------------------
Version 1.12.13 (v1.12.13-0-g969649d from master-1.12)
Copyright 1998-2016 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with
GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, without Python, with GnuTLS 3.2.15, with Gcrypt 1.6.2,
without Kerberos, with GeoIP, with PortAudio V19-devel (built Jul 27 2016), with
AirPcap.
Running on 64-bit Windows Server 2016, build 14393, with WinPcap version 4.1.3
(packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b
(20091008), GnuTLS 3.2.15, Gcrypt 1.6.2, without AirPcap.
Intel(R) Xeon(R) CPU E7- 8870 @ 2.40GHz, with 8191MB of physical memory.
Built using Microsoft Visual C++ 10.0 build 40219
Broken in 1.99.0 and later. Here is my 1.99.0
-------------------------------------------------------------------------------
Version 1.99.0 (v1.99.0-2-g9033f13 from master)
Copyright 1998-2014 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with Qt 5.3.1, with WinPcap (4_1_3), with libz 1.2.5, with
GLib 2.34.1, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, with GnuTLS
3.2.15, with Gcrypt 1.6.2, without Kerberos, with GeoIP, without PortAudio, with
AirPcap.
Running on 64-bit Windows Server 2012 R2, build 9600, with Npcap version 1.50,
based on libpcap version 1.10.1-PRE-GIT, with GnuTLS 3.2.15, with Gcrypt 1.6.2,
without AirPcap.
Intel(R) Xeon(R) CPU E7- 8870 @ 2.40GHz (with SSE4.2), with 8191MB of
physical memory.
Built using Microsoft Visual C++ 12.0 build 30501
For Example 2, this was broken in 1.99.2 and later. Here is my 1.99.2
-------------------------------------------------------------------------------
Version 1.99.2 (v1.99.2-0-gb2db3bf from master)
Copyright 1998-2015 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with Qt 5.3.1, with WinPcap (4_1_3), with libz 1.2.5, with
GLib 2.42.0, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, with GnuTLS
3.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, without PortAudio,
with AirPcap.
Running on 64-bit Windows Server 10, build 17763, with locale C, without
WinPcap, with GnuTLS 3.2.15, with Gcrypt 1.6.2, without AirPcap.
Intel(R) Xeon(R) CPU E7- 8870 @ 2.40GHz (with SSE4.2), with 16382MB of
physical memory.
Built using Microsoft Visual C++ 12.0 build 31101
For Example 2, this works in 1.99.1 and earlier. Here is my 1.99.1
-------------------------------------------------------------------------------
Version 1.99.1 (v1.99.1-0-g4c229ca from master)
Copyright 1998-2014 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with Qt 5.3.1, with WinPcap (4_1_3), with libz 1.2.5, with
GLib 2.42.0, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, with GnuTLS
3.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, without PortAudio,
with AirPcap.
Running on Windows NT, unknown version 10.0, build 14393, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), with GnuTLS 3.2.15, with Gcrypt 1.6.2, without AirPcap.
Intel(R) Xeon(R) CPU E7- 8870 @ 2.40GHz (with SSE4.2), with 8191MB of
physical memory.
Built using Microsoft Visual C++ 12.0 build 30501