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).