Is there any way to display (filter) only those AOE (ATA over Ethernet) protocol request messages which do not have corresponding responses? I.e., when there are no matching response message with the same value of AOE Tag and response flag set in the Flags field?
In general this is difficult as filters only operate on a single packet at a time, it's either in or out based on the contents of the packet.
For protocols that include a link to the response in the request, as AOE does with the aoe.response_in field, then you should be able to filter on this. I'm unable to test this (I have no AOE captures) but try !aoe.response && ! aoe.response_in. This first part should select AOE requests, the second part limits to those without the response_in field.
Another possibility is MATE, now documented in the User Guide too.
Thanks, the expression "(aoe.response == 0) && !aoe.response_in" seems to work.
Ah yes, the change to the first part of the condition ensures the field is present and not set, this will only in AOE requests. My original version would select all packets that didn't have the aoe.response field which could include a lot of other packets other than AOE requests.
One interesting thing in addition: it seems that Wireshark tries to apply filter and colorization rules to the packet as soon as the log string corresponding to that packet is first presented to the user. This leads to incorrect marking of ALL AOE requests as if they are matched this filter, if "Autoscroll in live capture" checkbox is set, since at the moment when request is being sent, response is not exist (yet). I found a workaround: one can uncheck and then re-check "Colorize packet list" menu item under "View" main menu item. After this Wireshark recalculates coloring rules values to displayed log strings.
This ia a consequence of live capture. When the AOE request is dissected there is no information about the response has it hasn't yet been received so the field can't be added. Your work-around forces a second dissection pass over the packets and now when dissecting the request the info about the response is available. When opening an existing capture file the 2 passes are done automatically, for tshark you have to add the -2 parameter to run the 2nd pass.
You might find also scrolling the packets out of and back into view might redissect them causing the info to be added.
Comments