Wireshark mailing list archives

Architecture of wireless timeline viewer


From: Simon Barber <simon.barber () meraki net>
Date: Mon, 24 Apr 2017 17:04:34 -0700

Currently the wireless timeline viewer is implemented as so:

1. patch to add single packet duration calculation to the wlan_radio
dissector (merged)
2. patch to enhance this to add aggregate detection, and calculation of
packet start and end times (not merged)
3. a patch to allow the GUI to call into the protocol
4. a patch to add a GUI that displays a timeline using the start and end
times calculated in 2. (not yet merged)

Currently 2. uses some protocol packet data to handle the state necessary
for tracking aggregate subframes from various generators that do not
include timing information in all frames. Also for storing the packet start
and end times, so that the GUI can access them quickly when rendering the
timeline at low zoom levels (where many packets may need to be accessed to
generate the display).

Currently 4. uses a new function to allow access to protocol data from the
frame number to get the packet start and end times.  - adds function
p_get_frame_data() to proto.c
This function used to exist, but was removed a while ago.

In addition 4. uses a new machanism introduced by 3. to allow the
wlan_radio protocol to track whether every frame in a capture has
sufficient information to determine both start and end time. If not then
the GUI will not display the capture. Some generators sometimes drop
essential timiing information perhaps from many or just a few packets.

The issue here is the fairly tight coupling between the GUI and the
wlan_radio protocol - this is new. The GUI must be able to addess packet
timing (start and end time) fast, for the display. The wlan_radio protocol
needs to track state to determine these times.

Sometimes the wlan_radio protocol goes back and changes packet timing
information from already dissected packets (e.g. when there is a generator
that only includes timing information on the last packet in an aggregate) -
so a tap to deliver timing information from protocol to GUI once on the
first dissection pass will not work.

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

Current thread: