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

Wireshark-dev: [Wireshark-dev] Problem with tcp_dissect_pdus

From: Andrew Schweitzer <a.schweitzer.grps@xxxxxxxxx>
Date: Sat, 18 Nov 2006 17:19:51 -0500
I'm having problems using tcp_disscet_pdus with a proprietary protocol. Wireshark appears to be "losing" packets (not parsing them with application level dissector) in cases where relatively large amounts of packets are sent from one end.

I believe this is similar to the problems reported here:

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1124

John R. H, I believe you had a work around... can you post that?

This happens quite often with our stuff, and makes wireshark difficult ot use for our purposes. I don't think it's a bandwidth problem, I don't think it's that many packets. I think it's a problem in wireshark treating the packets as stream. I don't think wireshark is dropping packets. They all appear to be there if you parse the raw tcp by disabling our dissector. I think they are getting "lost" due to one or more problems with PDUs spanning packets. It might happen in our system a lot because we have big-fast pc talking to a little-slow embedded system.

Any suggestions on best way to work around this? Or what to modify in the wireshark code?

I have at least two cases. PDU header length passed to tcp_dissect_pdus is 2. The first 2 bytes of the PDU contain its length.

-----------------------------------------------------
Case #1:
Frame 1
offset
0	ethernet		
16	ip
36	tcp
66	PDU_Len: 1444 bytes	
68	PDU_Data: 1442 bytes of it
1510	First 4 bytes of *next* PDU... or...
	PDU_Len and 2 byets of PDU_Data of next PDU. PDU_Len is 52.
	Since there are only  1514 bytes available, PDU has to overlap. 	

Frame 2
offset
0	ethernet		
16	ip
36	tcp
66	PDU_Data (PDU_Len was in last frame)
	-->--> 	But here wireshark treats the first two bytes of
	-->--> 	PDU_Data as the PDU_Header... it seems to have
	-->--> 	forgotten that it got PDU_Len at end of last frame!
	-->-->  The len here is very large, and this frame just doesn't
	-->-->  get passed to protocol.

Note that since the PDU_Len doesn't overlap the frame, this this might not be same as bug 1124 listed above.

-----------------------------------------------------
Case #2
Frame 1
offset	
0	ethernet		
16	ip
36	tcp
66	PDU_Len1: 864 bytes	
68	PDU_Data1: 862 bytes of it
930	PDU_Len2: 332 bytes	
932	PDU_Data2: 330 bytes of it
1262	PDU_Len3: 376 bytes	--> this will overlap	
1264	PDU_Data3:  250 bytes of it

Frame 2
0	ethernet		
16	ip
36	tcp
66	PDU_Len3 continued...
	-->-->	But wireshark thinks this is another PDU and treats it
	-->-->	as PDU_Len3.


Thanks,

Andy