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