RadioTap Archive on
 help / color / Atom feed
* [RFC] capture file timestamping
@ 2015-08-25 10:07 Johannes Berg
       [not found] ` <>
  0 siblings, 1 reply; 7+ messages in thread
From: Johannes Berg @ 2015-08-25 10:07 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A; +Cc: Simon Barber

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

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?


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-25 10:07 [RFC] capture file timestamping Johannes Berg
     [not found] ` <>
2015-08-25 16:28   ` David Young
     [not found]     ` <>
2015-08-25 16:46       ` Johannes Berg
     [not found]         ` <>
2015-08-25 17:47           ` Guy Harris
     [not found]             ` <4E4FE63E-B636-4808-BBFF-6D2CE4EAFB2F-FrUbXkNCsVf2fBVCVOL8/>
2015-08-25 17:55               ` Johannes Berg
2015-08-26 22:48           ` Simon Barber
     [not found]             ` <>
2015-09-17 16:51               ` Johannes Berg

RadioTap Archive on

Archives are clonable:
	git clone --mirror radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ \
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone