Re: 802.11 timeline view and aggregation

[Simon Barber <simon.barber () meraki net>]

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 () alum mit edu> wrote:

> On May 29, 2015, at 9:04 PM, Simon Barber <simon.barber () meraki net> 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 () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe