https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7902
--- Comment #35 from Chris Bontje <cbontje@xxxxxxxxx> 2012-10-26 09:11:11 PDT ---
(In reply to comment #34)
> (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).
In addition, this rule only applies to that single pcap file that contains
actual "serial" data, not the proper full Ethernet-captures that properly
segment the Modbus RTU "data" component.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.