Re: DNP3 message spanning multiple TCP packets bug

[Chris Maynard <Christopher.Maynard () gtech com>]

Graham Bloice <graham.bloice@...> writes:

>     Actually
>         thinking about your problem description a little more, the DNP3
>         dissector needs to see at least two bytes in the TCP packet (the
>         0x0564 data link layer start sequence) to determine that the
>         data is DNP3.  If your device is only sending back one byte per
>         tcp packet then I don't think the dissector will pick it up.
>         Most (all) of the serial port to IP devices I've used have a
>         buffer or delay setting to not transmit an IP packet until a
>         number of characters have been received or no characters have
>         been received for a time period (i.e. end of serial packet).  Do
>         you have any settings on your device to do this?  Apart from
>         allowing Wireshark to correctly decode the data, it will also be
>         much more efficient for your end use case.-- 

And looking at the dissect_dnp3_tcp() function, I don't think that's the way it
should work because tcp_dissect_pdus() is told how many bytes it needs
(DNP_HDR_LEN) before passing off dissection to to dissect_dnp3_message().  I
think those heuristics in both dissect_dnp3_tcp() and dissect_dnp3_udp() should
be moved inside dissect_dnp3_message().  The packet-ancp.c dissector works this
way, and I'm sure there are others that do the same (I didn't look too hard 
though).

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe