https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7902
--- Comment #20 from Chris Bontje <cbontje@xxxxxxxxx> 2012-10-23 08:20:21 PDT ---
(In reply to comment #19)
> Are you talking:
> 1. Modbus RTU over "raw" Ethernet (not TCP/IP)? If that's the case the Modbus
> RTU dissector would need an different/additional hook into the Ethernet frame,
> not a port number. It appears some of the captures provided display this
> behavior. I would differ to others as to the best way to do that.
>
> 2. Modbus RTU over TCP/IP where Unit ID + Modbus PDU is sent over Port 502
> instead of the MBAP header? I would technically consider this a "violation" as
> port 502 is reserved for Modbus/TCP. From an implementation standpoint I would
> create a preference for the "Modbus RTU port", but default it to 0, not 502 to
> prevent inadventent collisions. Users would then have to pick between
> Modbus/TCP and Modbus RTU by either changing ports or disabling one of the
> protocols. There is also the possibility of not assigning it a port at all and
> just making it available to the "Decode As..." functionality.
>
>
#2 is what is typically seen, but port 502 is not used; most of what I see is
Modbus RTU serial data encapsulated into a standard TCP/IP message, over a
configurable port (ie: 10001 in the Modbus_Tunneled_* examples above). I think
a separate port configuration option for Modbus RTU over TCP makes the most
sense if we are to keep the protocols completely independent. I think
"decode-as" will not allow us seamless use of the "packet direction detection"
code, which checks if a given port number is the src or dst in a given packet.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
