ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] TCP problem

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 19 Jun 2008 11:51:16 -0700
Sabyasachi Samal wrote:

I am having one problem while sending SIP messages over TCP transport. Some times wireshark shows

[Unreassembled Packet [incorrect TCP checksum]: SIP] . Why this error is coming?

If that packet was sent by the machine running Wireshark, it might have been sent on an interface that does TCP checksum offloading:

	http://wiki.wireshark.org/TCP_checksum_offload

(you might be running an older version of Wireshark which didn't specifically note that this might be due to TCP checksum offloading).

See the Wiki page listed above for information on why this causes checksum errors to be reported and how to turn checksum checking off.

Turning checksum checking off causes Wireshark to reassemble the two segments into a single SIP message.

At other side it displays [TCP segment of a reassembled PDU]. Please let me know what does this mean

It means that Wireshark was trying to reassemble a SIP message that was in more than one TCP segment. If that segment eventually shows up in a reassembled PDU, there's no problem. In the PS.pcap capture, that's what's happening - the SIP message in that packet has some of its data in packet 1 and some of its data in packet 3.

Those two captures appear to be of the same traffic, presumably just taken on different machines (one on the machine sending the SIP traffic, and one on the machine that's just acknowledging the TCP segments).

That message looks a little strange, though - I'm not familiar with SIP, but if it follows the same model as HTTP, it appears to contain a request:

	REGISTER tel:home1.net SIP/2.0

and a reply:

	SIP/2.0 200 OK

There's no blank line in the TCP stream between them; perhaps this is a bug in the sending SIP implementation (if there's supposed to be a blank line at the end of the REGISTER request), perhaps this is a bug in Wireshark's dissection of the REGISTER request (if there's *not* supposed to be a blank line at the end of the REGISTER request, and something else marks the end of the REGISTER request), or perhaps this is a bug in my assumptions about SIP (if that really *is* a single message).