https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7902
Michael Mann <mmann78@xxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #9425| |review_for_checkin?
Flags| |
--- Comment #24 from Michael Mann <mmann78@xxxxxxxxxxxx> 2012-10-23 20:57:36 PDT ---
Created attachment 9425
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9425
More updates to Modbus/TCP + RTU
Here's what I did:
1. Added more "proto" data to get rid of some of the ugly global variables
(note the modification of the CIP dissector)
2. Separated out the "classify packet function" since they were functionally
different anyway (and Modbus RTU has some additional "classifying" to do when
it comes to serial)
3. Reworked the display filter names so that "modbus" is the prominent
dissector/filter. Modbus/TCP and RTU just have their "header" fields
4. Added filters for the diagnostic function values
5. Made "register values" filterable
The only thing that really needs to be done before the patch is accepted is to
get rid of global_mbus_register_base. I see 2 solutions:
1. Not have register offsets displayed (which is how it worked previously)
2. Add "conversation data" with the transaction id. See
README.request_response_tracking for implementation hints, although I think
you'll run into problems with long captures where the transaction ID rolls over
or a capture where transaction ID is always 0. Remember that transaction IDs
aren't guaranteed to be sequential or you could have multiple requests before a
single response so the "global variable" will do more harm than good.
Some "nice to haves" while the Modbus dissectors are being modified (but I
won't hold the patch up for them):
1. CRC validation for Modbus RTU (with on/off preference). Note that
algorithms should be put in wsutil folder (maybe the Modbus CRC algorithm
already exists there (in a generic form), I haven't checked)
2. Make a better attempt at getting the packet size for an RTU packet.
Requires dissecting into function code but it better allows for multiple
packets to be dissected in a single frame. Without this, tcp_dissect_pdus is
less useful. It will do "one PDU across multiple frames", but not "multiple
PDUs in a single frame" without better length calculations.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.