https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3315
Sake <sake@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #2837 is|0 |1
obsolete| |
--- Comment #3 from Sake <sake@xxxxxxxxxx> 2009-03-10 00:46:36 PDT ---
Created an attachment (id=2838)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2838)
One dnp3 session
I filtered one dnp3 stream from the file to work with. The issue here is that
when you filter on higher layer protocols, such as dnp3, there is re-assembly
of data on lower protocols, in this case TCP. If you look at frame 137
(corresponding to frame 44674), you can see that it has been reassembled on the
TCP layer. The dnp3 data is devided over frame 135 and 137 (look at the TCP
details).
Since the filter 'dnp3' will only show the frames with the reassembled data,
saving only the displayed packets, so it will not save frame 135. However, in
the new file, the original frame 137 can not be detected as dnp3, as the first
part of the dnp3 data is missing. This is a result of how wireshark filters and
re-assembles.
As a workaround (in this case) you could filter on "tcp.port==20000 &&
tcp.len>0" to get all the dnp3 application data in the new file.
I will leave this bug-report open as a "request for Enhancement" so that maybe
in the future it will be possible to also save all fragments that are not
displayed, but needed for proper dissection.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.