I am pretty familiar with DNP3, slightly less familiar with Wireshark though I am comfortable with it. I am just starting to use Wireshark to decode DNP3 data. I noticed that the filter includes "dnp3.al.ana" which seems to specify that a particular analog point offset exist in any filtered packets. However, I do not see how to also specify a value. The descriptions at the DNP3 Wireshark Display Filter Reference are pretty vague, perhaps it is there and I am missing it. Some example use cases where this would be handy: An example use case is when a serial number is passed back as a point, in case you know the device serial number you're interested in but don't have a cross reference sheet to find the device's DNP3 address. Or, troubleshooting an issue and identifying exactly when a particular value came across. Another example with particular worth is identifying binary values (e.g. reporting a local operation) that came in unsolicited; you can filter on the unsolicited flag, but unless the binary value came back as "with flags" instead of packed I cannot see how to filter on its value. Any help is appreciated. I can also generate DNP3 pcap files if anyone wants to see what I'm working with. asked 04 Apr '16, 12:44  DerekGuenther |
One Answer:
The filter you mentioned, as do all Wireshark display filters, matches against the value of the specified field, e.g. a filter of Note that this field has changed recently in the nightly builds and whenever 2.2 is released. Currently you can just use For (single-bit) binary values you can only search for 0 or 1, using Arguably the filter names for status bits should reflect the status name not the bit position, but changing them now would upset folks with working filters using the current names. Also note that often the easiest way to determine a filter is to find a field with the value you want in the packet details pane, right click the field and choose "Apply as a filter -> Selected". answered 04 Apr '16, 16:15  grahamb ♦ |
Thank you, this is helpful, particularly the bit about right-clicking and applying as a filter. However, if I apply a display filter "dnp3.al.point_index == 6 && dnp3.al.ana == 1317" (sorry, I don't know how to format in a comment) it seems to display all packets that contain the specified analog point index and does not actually filter on the value. That is why I was confused about what dnp3.al.ana did, because it does not seem to work. It is also definitely broken for 32-bit values, right-clicking on one and applying as a filter causes no packets to appear even though that particular point (a serial number) only ever has one value in all of the messages.
If it matters, I used a comms log from our head-end software and ran it through text2pcap. The DNP data should be the same either way, I believe. If you would like me to provide a capture file or screenshots I'd be happy to, I am still open to the possibility that I might be doing something wrong.
Thanks again for your help, it is much appreciated.
Can you try one of the more recent nightly builds? This may be a reason for the change I mentioned.
Sorry for the delay in responding. I installed "Version 2.1.0-2685-ga7e04fc (v2.1.0rc0-2685-ga7e04fc from master)" just now and tried again. The "dnp3.al.ana.int" filter seems to work a lot better. It works for 32-bit values now, and seems to filter properly for 16-bit as well where the old filter just seemed to give you every packet.
However, I'm still having an issue - let's say that I apply the filter "dnp3.al.point_index == 13 && dnp3.al.ana.int == 1235" as I am trying to find times that the reported voltage (with a x10 multiplier) on point offset 13 was 123.5 Volts. Instead of "show me only the packets where analog input point 13 was 1235" I get "show me the packets where analog input offset 13 was present, and any random analog input point happened to have a value of 1235". For example, I have a packet where the value of offset 13 was 1236 (but it is present in the scan return) and point offset 11 had a value of 1235. Both conditions are satisfied, there is a point with that offset and there is a point with that value, but they are not one in the same which is what I want.
Any thoughts on that? I'm guessing since the filters have changed so much in the new version that it is a work in progress and I'll just have to wait until it gets fixed. If you have a way to let them know about the problem or can tell me how to report this bug, that would be awesome.
Thanks for your help, grahamb. I'm accepting your answer as you have definitely steered me in the right direction, it is a limitation in the current builds of Wireshark that I cannot get what I want.
This is a limitation of Wireshark filters, both display and capture in that the filter is used as a packet matcher, and as long as the filter expression returns true when tested against a packet, then the packet is good.
For protocols such as DNP3 with multiple repeated elements, there is no ability (currently) to express the requirement that the point index and value must be constrained to the same data element (i.e. same sub-tree in the packet detail pane).
The DNP3 dissector could be modified to add a synthesised field for each data element that combines the index and value. such as "index:value", then a filter could be written to match against that, e.g. dnp3.data_element == "13:1235" which would work for digitals and integers but be somewhat difficult for floating point values as you would have to specify the digits exactly as we've now switched to a string comparison.