I understand that the default order Wireshark is sorting frames is the frame number. Displaying either "Delta Time Displayed" or frame.delta_time_displayed will show the time difference between two frames based on the sorting by frame number. Unfortunately the "Delta Time Displayed" (∂t) is not being calculated again after one changes the order by sorting by column. I will give an example. I have to analyse a lot of captures with HTTP traffic and thus display the tcp.stream as a column and often sort by it to get the consecutive http.requests and http.responses. When filtering for a single stream for example with: tcp.stream == 1234 and (http.request or http.response) The value for ∂t are correctly displayed. It starts to get problematic when not only a single stream is displayed but several. After having applied the filter: http.request or http.response with more then one stream available the frames will be displayed sorted by the frame number and ∂t will be calculated like wise. By clicking on my column tcp.stream the order of the frames will be changed but ∂t will not be calculated again based on what is shown now, thus all colouring rules based on ∂t will not work. As far as I can see there are three possible workarounds for this:
I haven't found any way how to do either of them and thus my question: How can I get ∂t to show the correct values even after re-sorting the frames by clicking on any column? asked 29 May '12, 06:22  teoh |
3 Answers:
How can I get ∂t to show the correct values even after re-sorting the frames by clicking on any column? Well, the delta times are showing the correct values, they're just not showing the values you want them to because currently the delta time computed is always from the previous displayed packet based on frame number, not from the previous frame based on sort order. So, in order to have the delta time computed based on the current sort order, Wireshark would obviously need to be changed to handle this. However, there is at least one implication to this that would have to be resolved. For example, what happens to the delta times if you sort on the delta time column itself? This feature request has been brought up before but was rejected, in part due to concerns I had about it; however, maybe it is worth implementing as long as the delta time column sort order problem can be ... um ... sorted out. Refer to bug 3481, which you're free to reopen if you want. answered 29 May '12, 19:38  cmaynard ♦♦ |
Well, as long as the traffic is TCP, as in your case, you can make use of "tcp.time_delta" and "tcp.time_relative" to get the timestamps for each specific TCP stream, without having to sort on tcp.stream. There i however no "tcp.time_delta_displayed" which you would need if you want to filter on http requests and responses. answered 31 May '12, 01:09  SYN-bit ♦♦ That's a good thought. I looked into that and found that using "tcp.time_delta" or "tcp.time_relative" won't do the trick. First of all because a server will send an [ACK] when receiving the http.request. Secondly a http.response (most likely) spans over several frames and Wireshark shows the http.response when the last frame is being received. Thus both "tcp.time_delta" and "tcp.time_relative" will not show the actual time between an http.request and an http.response but more likely between the frames in between. (01 Jun '12, 00:25) teoh |
yes, that's correct. However you can circumvent this, by using the following display filter:
This will only show the packet with the GET request (or any other method you specify) and the packet of the HTTP response. It's not 100% reliable, but better than nothing ;-) Alternatively you can filter on other HTTP request headers as well.
Regards answered 01 Jun '12, 01:55  Kurt Knochner ♦ edited 01 Jun '12, 01:56 |
I thanks for the answer. I am aware of the problem and agree that the bug mentioned is correctly marked as INVALID that's why I though it could be possible to implement a display-filter defining a custom sorting order and implement a change on how ∂t is computed according to that sorting order.
I don't think the current
"delta time (displayed)"behavior should be changed. Rather, I was thinking that a new"delta time (sorted)"column could be added instead. And when sorting on the new"delta time (sorted)"column, it should revert to the same as how"delta time (displayed)"would sort ... or if possible, simply disallow sorting by that column.sound would be perfect indeed ;)
FYI, I reopened bug 3481 ... now someone just needs to implement it. :)