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
