Re: [RFA] timestamp field
Simon Barber <[email protected]> Wed, 03 Feb 2016 14:29:42 -0800
| Newsgroups | org.netbsd.radiotap |
|---|---|
| Message-ID | <[email protected]> |
My wireshark timeline code is out for early review. https://code.wireshark.org/review/#/c/13694 Simon Sent with AquaMail for Android http://www.aqua-mail.com On January 20, 2016 11:40:14 PM Johannes Berg <[email protected]> wrote: > On Wed, 2016-01-20 at 09:46 -0800, Simon Barber wrote: >> I like this proposal. One aspect that is missing is to define the >> meaning of the timestamp with aggregates. Should this field be >> present for all subframes, or just the first/last? Should the >> timestamp refer to the subframes, or the whole A-MPDU? Currently what >> I see in different generators is the MACTIME field is either the same >> for all subframes, and always refers to the whole A-MPDU - not >> individual subframes. For one generator the MACTIME was 0 for >> subframes after the 1st. Sometimes the signal strength is only >> present on the last subframe. > > Yeah, I had actually noticed this - our device also has the PHY > acquisition timestamp of the A-MPDU, in all the frames. We should > probably elide it in all but the first, but if we somehow lost the > first frame that would be bad. I'm not even sure you can identify that > today at all though. > > I don't think we can *standardise* the behaviour, but perhaps providing > flags for the different behaviours would at least help you identify it? > > Any thoughts what flags would be useful? > >> Macbooks generate radtiotap files with incorrect rate fields for >> subframes with CRC errors. > > That's a bit odd. Talk to Broadcom? ;-) > >> If you look in the wireshark gerrit, you will see I have been porting >> my timeline viewer code over to the current devel mainline. >> > > Very nice! :) > > johannes