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

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Reply via email to