Hi,
Thanks for the capture file that illustrates the problem.
I have checked in a fix to stop ethereal from misdiagnosing these
packets for ModBus/TCP. It is in SVN 16811 and later.
I changed the modbus/tcp dissector to do some very basic sanity
checking of the packets and reject them if they are obviously not
modbus/tcp.
Doing this i also noticed, and fixed, two instances where the
dissector just did a memcpy from the buffer straight into a structure,
which is obviously broken and just can not work. (except on a very
very small number of hosts where by chance the compiler by random
coincidence just happens to lay the structure fields out the same way
as they are encoded.)
On 12/14/05, Scott Waddell (swaddell) <swaddell@xxxxxxxxx> wrote:
> Hello,
>
> I'm working with some packet traces from the NLANR Passive Measurement &
> Analysis (PMA) project that have packets truncated as part of their
> trace anonymization process.
>
> In one sample from the NLANR PMA site at Purdue (attached), there is
> some traffic that ethereal classifies as Modbus/TCP. I don't think this
> is actually Modbus traffic as all the protocol fields are zero so, for
> example, the function code of zero is an "Unknown function", etc.
>
> I've included all the traffic from the trace involving the hosts with
> supposed Modbus traffic in case it helps with the analysis. A display
> filter of "tcp.port==502" will show the candidate Modbus packets.
>
> I'm not certain this is a bug, but ideally it seems that the Modbus
> dissector in ethereal would check the values in the various Modbus
> fields to make sure they're valid known function codes, etc., before
> classifying the packet as Modbus/TCP.
>
> Thoughts?
>
> Thanks,
> Scott
> __
> Scott Waddell
> Research Engineer
> Critical Infrastructure Assurance Group (CIAG)
> Cisco Systems, Inc.
> swaddell@xxxxxxxxx
> 512-378-1230
>
>