[Simon Barber <simon.barber@xxxxxxxxxx>]

The main thing that is 802.11 specific is that it relies on the hardware timestamps (radiotap.mactime) to have guaranteed accuracy. The 802.11 mac relies heavily on frame timing, and the extension splits into 2 parts - 1 part that calculates frame durations and start and end times from the available radiotap information, timestamps, and details of what physical layer framing and headers are in use. It also calculated the inter-frame spaces that are so important to the 802.11 MAC, and another part of the code that uses all this data and provides the visualization. I imagine this kind of display would be very useful for other, non 802.11 protocols as well, although software based timestamps would mean that the display might not be perfectly accurate. Also with software based timestamps sometimes packets can appear to overlap, and that would need to be resolved.

No documentation was written, and I don't have any screenshots (although the functionality worked very well the niceties of the GUI were never finished). The packet timeline was rendered anti-aliased, so when zoomed out you could see the density of traffic vary over a large period of time, and when you zoomed in you could see single microseconds. I am currently working to bring the code up to date and get it building on the master branch. I can take some screenshots when I get the code running. This is partly why I was asking questions about whether the gtk build is expected to work in the current master branch - since all the visualization code was gtk. I was also previously developing on Debian, but am now using Mac OS (which I am not very familiar with), and have been having trouble with getting the master branch to build. QT is working, but GTK is not yet for me.

I imagine the code from github would build quite easily on a 2 or 3 year old Debian or Ubuntu OS image. It does not display the timeline unless all the required physical layer information is available from radiotap to correctly calculate the packet durations. Also on github are patches to the linux kernel to have the intel drivers include all the required information in the radiotap captures.

On Mon, Jun 1, 2015 at 7:29 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On May 29, 2015, at 9:04 PM, Simon Barber <simon.barber@xxxxxxxxxx> wrote:

> A few years ago I wrote an extension for Wireshark that allows 802.11 frames to be viewed on a zoomable, scrollable timeline in a third pane added to the main display.

Is there anything 802.11 specific about this - and, if so, are there parts that aren't 802.11-specific and that would be useful for other link layer types?

Is there some documentation of what it does, preferably with a screenshot?

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe