https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7902
--- Comment #28 from Michael Mann <mmann78@xxxxxxxxxxxx> 2012-10-24 11:17:59 PDT ---
(In reply to comment #26)
> I'm not quite
> clear as to where the modbus_request_info_t structure is defined (and how new
> components like register_addr_type, etc got added); is it a dynamic data
> structure we can just assign elements to?
It's data associated with a protocol for a specific frame. It's one of the ways
to pass data between dissectors (within the same frame). If the Modbus
dissector sees "context data" for its protocol, its acts accordingly, otherwise
it defaults to "RAW, UINT16 registers". You would add additional members to
the modbus_request_info_t structure (in packet-mbtcp.h) if you felt the Modbus
dissector needed more "context" from upper layer protocols (like Modbus/TCP and
RTU). This is different than the "conversation data" you'll need to match
request/response.
> I was also considering going through
> the filter names and adjusting things to split out the different categories -
I tried to complete that thought, but maybe you were looking for more filters
specific to each function code? I waiver on how much the "modbus.data" filter
should be used. It's easier to write a filter for "modbus.data" == <some
bytes> then modbus.holdingregister.data == <some bytes> ||
modbus.inputregister.data == <some bytes>, etc, but the "modbus.data" filter
also returns more results (and you can include the function code as part of the
filter)
> With Modbus RTU (at least) we can be guaranteed that there will be no
> situations where two requests are issued sequentially; normal conversations
> will always go poll->response, poll->response, etc.
Wireshark can be used to troubleshoot when "conversations" aren't normal (like
missed responses or duplicate responses), and you would hope the dissection
would be as accurate as possible. Dissectors aren't written for just the
"happy" case.
In that case, with a
> response, couldn't we reference the packet context fields to simply step
> backwards through the packet lists (from our current point), find the last
> query from current dst addr, and take the reference_number base from there?
> This would just require us to store and then reference the reference_number -
> or am I misunderstanding the capabilities of the packet context functionality?
> "Transaction ID" only applies to Modbus/TCP messages and wouldn't to Modbus RTU
> so we'll need a solution for both. I've also got captures from systems where
> the Transaction ID is zero, as you noted above so we aught to not use that.
> The Modbus/TCP systems I've worked with will typically still follow the same
> poll->response pattern from the Modbus RTU world, do you have captures where
> two different polls are issued sequentially? I'll attach a typical capture
> that I see, it has a master polling a slave with 4 different holding register
> polls, each one seems to be split?
Once you are on TCP (and not a serial bus) you have the ability to have
"multiple conversations" in a single capture. So you could have 1 master
polling 4 different slaves concurrently (with some of the requests being
"outstanding" while other responses come in) or 4 separate masters each polling
their own 1 slave. This is where having a global varible that assumes a
single, sequential "conversation" is dangerous.
You are also not guaranteed after the "first pass" over each frame that a
dissector will access frames in sequential order.
Unfortunately, I just think matching request/response on the wire is a
limitation of the protocol it terms of being able to do it deterministically.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
