From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org
Cc: Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
Subject: [RFC] capture file timestamping
Date: Tue, 25 Aug 2015 12:07:09 +0200 [thread overview]
Message-ID: <1440497229.2192.28.camel@sipsolutions.net> (raw)
Hi all,
[Simon brought up a related topic a few years ago]
We have a field for TSFT/mactime, which is defined as follows:
Value in microseconds of the MAC's 64-bit 802.11 Time
Synchronization Function timer when the first bit of the MPDU
arrived at the MAC. For received frames only.
This is great, but not always feasible. Particularly when operating
within multiple virtual interfaces and trying to record data from the
hardware at the same time, the TSFT is either unobtainable or
practically useless.
Similarly, in actual monitor mode, there might not be a TSF timer -
just a base hardware timer that is essentially free-running (though
with the same frequency.)
As Simon also found, the reference might not be the "first bit of the
MPDU" (which I'd also say is actually somewhat vague with OFDM
symbols), but something else entirely.
There's also something that I'm not sure about - in 5/10 MHz channels,
as I understand this is often achieved by running hardware timers at
different frequencies - does that affect the timestamps hardware
reports here?
I'm not sure we'll be able to capture everything in a single value, but
we could add a field that has a "type" that can be extended in the
future.
Say, for example, we add a new field like this:
Structure: u64 timestamp, u32 flags
Alignment: 8
We'd probably need flags for
* TSF timer
* first bit/symbol of MPDU
(these two allow reproducing the existing TSFT field functionality,
which might not be necessary, but each could still be useful)
* 32-bit only [our hardware only has an internal 32-bit timestamp]
* end-of-frame [maybe define this better?]
We could also go into the various other places of the frame where a
timestamp can be taken - our hardware does it when it detects energy on
the air.
The most common use for this would really be looking at monitor files,
so for me personally simply having a more generic "timestamp" field
that doesn't specify much of its semantics would be sufficient -
however, I believe that to be very dangerous as somebody's semantics
will eventually get hard-coded into wireshark and then it's fixed
anyway ...
Anyone want to offer any thoughts?
johannes
next reply other threads:[~2015-08-25 10:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-25 10:07 Johannes Berg [this message]
[not found] ` <1440497229.2192.28.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2015-08-25 16:28 ` [RFC] capture file timestamping David Young
[not found] ` <20150825162841.GR6823-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
2015-08-25 16:46 ` Johannes Berg
[not found] ` <1440521168.2192.50.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2015-08-25 17:47 ` Guy Harris
[not found] ` <4E4FE63E-B636-4808-BBFF-6D2CE4EAFB2F-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-08-25 17:55 ` Johannes Berg
2015-08-26 22:48 ` Simon Barber
[not found] ` <55DE4244.9030407-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2015-09-17 16:51 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1440497229.2192.28.camel@sipsolutions.net \
--to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
--cc=radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org \
--cc=simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).