https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7902
--- Comment #34 from Chris Bontje <cbontje@xxxxxxxxx> 2012-10-26 09:09:36 PDT ---
(In reply to comment #33)
> (In reply to comment #32)
> > (In reply to comment #31)
> > > Comment on attachment 9412 [details]
> > > Modbus RTU (Serial) for use with User_DLT Dissector ("Modicon Float" data
> > > types)
> >
> > As far as the CRCs go, I assume you speaking of the CRCs for the Modbus RTU
> > packets? They all checked out as valid on my test equipment/software (from a
> > variety of manufacturers) and they are reported valid by the CRC-16 "Modbus"
> > algorithm as found on this web site (albeit, displayed in reverse byte order):
> > http://www.lammertbies.nl/comm/info/crc-calculation.html
> > Chris
>
> Packet/Frame 2 shows a CRC of 0xB079. For that packet, the website shows a CRC
> of 0x8F3B which agrees with my current CRC calculations (assuming correct
> endianness). What am I missing?
Oh, I understand whats happening with that message. The first 12 bytes of that
serial packet should be ignored (by using the user DLT preferences for a
12-byte header protocol of "data"). This data represents the state of the
various serial control lines on the device that captured the message (RTS/CTS,
DTR, etc).
The remaining 8 bytes represent the Modbus RTU message itself with the 6-byte
actual Modbus message of "020403fc004e" which gets a 2-byte CRC-16 of b079 (or
79b0 on the web-site).
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.