This makes mac80211 include the low-level MAC timestamp
in the radiotap header.
Signed-off-by: Johannes Berg <[email protected]>
---
net/mac80211/rx.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- everything.orig/net/mac80211/rx.c 2007-11-22 23:33:46.058691568 +0100
+++ everything/net/mac80211/rx.c 2007-11-23 11:45:10.422091198 +0100
@@ -82,6 +82,7 @@ ieee80211_rx_monitor(struct ieee80211_lo
int needed_headroom = 0;
struct ieee80211_rtap_hdr {
struct ieee80211_radiotap_header hdr;
+ __le64 tsft;
u8 flags;
u8 rate;
__le16 chan_freq;
@@ -157,7 +158,8 @@ ieee80211_rx_monitor(struct ieee80211_lo
memset(rthdr, 0, sizeof(*rthdr));
rthdr->hdr.it_len = cpu_to_le16(sizeof(*rthdr));
rthdr->hdr.it_present =
- cpu_to_le32((1 << IEEE80211_RADIOTAP_FLAGS) |
+ cpu_to_le32((1 << IEEE80211_RADIOTAP_TSFT) |
+ (1 << IEEE80211_RADIOTAP_FLAGS) |
(1 << IEEE80211_RADIOTAP_RATE) |
(1 << IEEE80211_RADIOTAP_CHANNEL) |
(1 << IEEE80211_RADIOTAP_DB_ANTSIGNAL) |
@@ -165,6 +167,8 @@ ieee80211_rx_monitor(struct ieee80211_lo
rthdr->flags = local->hw.flags & IEEE80211_HW_RX_INCLUDES_FCS ?
IEEE80211_RADIOTAP_F_FCS : 0;
+ rthdr->tsft = cpu_to_le64(status->mactime);
+
/* FIXME: when radiotap gets a 'bad PLCP' flag use it here */
rthdr->rx_flags = 0;
if (status->flag &
On Sat, 2007-11-24 at 18:36 +0900, bruno randolf wrote:
> On Saturday 24 November 2007 18:27:41 Mattias Nissler wrote:
> > On Sat, 2007-11-24 at 09:34 +0100, Johannes Berg wrote:
> > > On Sat, 2007-11-24 at 00:21 -0500, Michael Wu wrote:
> > > > On Friday 23 November 2007 05:45:54 Johannes Berg wrote:
> > > > > This makes mac80211 include the low-level MAC timestamp
> > > > > in the radiotap header.
> > > >
> > > > No thanks. Not every driver supports reporting the timestamp and
> > > > supporting timestamp/no timestamp in the default radiotap rx code makes
> > > > it not so simple anymore.
> > >
> > > Uh, so how am I supposed to get the timestamp? Copy all the code into
> > > b43 and make it generate the exact same radiotap header? That's pretty
> > > crappy too.
> >
> > On rt2x00, we've just added a facility that dumps information about all
> > frames received and transmitted at a very low level. We dump general
> > information about the frame, the tx/rx descriptors and the packet. Maybe
> > something similar would also be useful for b43?
>
> that's not a solution if you want them per packet in the radiotap header.
> kismet & wireshark use them as well as other applications.
We actually dump per packet data that is read via debugfs and then fed
into wireshark. Helps debugging a lot :-)
Mattias
On Friday 23 November 2007 05:45:54 Johannes Berg wrote:
> This makes mac80211 include the low-level MAC timestamp
> in the radiotap header.
>
No thanks. Not every driver supports reporting the timestamp and supporting
timestamp/no timestamp in the default radiotap rx code makes it not so simple
anymore.
-Michael Wu
On Sat, 2007-11-24 at 09:34 +0100, Johannes Berg wrote:
> On Sat, 2007-11-24 at 00:21 -0500, Michael Wu wrote:
> > On Friday 23 November 2007 05:45:54 Johannes Berg wrote:
> > > This makes mac80211 include the low-level MAC timestamp
> > > in the radiotap header.
> > >
> > No thanks. Not every driver supports reporting the timestamp and supporting
> > timestamp/no timestamp in the default radiotap rx code makes it not so simple
> > anymore.
>
> Uh, so how am I supposed to get the timestamp? Copy all the code into
> b43 and make it generate the exact same radiotap header? That's pretty
> crappy too.
On rt2x00, we've just added a facility that dumps information about all
frames received and transmitted at a very low level. We dump general
information about the frame, the tx/rx descriptors and the packet. Maybe
something similar would also be useful for b43?
Mattias
On Sat, 2007-11-24 at 00:21 -0500, Michael Wu wrote:
> On Friday 23 November 2007 05:45:54 Johannes Berg wrote:
> > This makes mac80211 include the low-level MAC timestamp
> > in the radiotap header.
> >
> No thanks. Not every driver supports reporting the timestamp and supporting
> timestamp/no timestamp in the default radiotap rx code makes it not so simple
> anymore.
Uh, so how am I supposed to get the timestamp? Copy all the code into
b43 and make it generate the exact same radiotap header? That's pretty
crappy too.
johannes
On Saturday 24 November 2007 18:27:41 Mattias Nissler wrote:
> On Sat, 2007-11-24 at 09:34 +0100, Johannes Berg wrote:
> > On Sat, 2007-11-24 at 00:21 -0500, Michael Wu wrote:
> > > On Friday 23 November 2007 05:45:54 Johannes Berg wrote:
> > > > This makes mac80211 include the low-level MAC timestamp
> > > > in the radiotap header.
> > >
> > > No thanks. Not every driver supports reporting the timestamp and
> > > supporting timestamp/no timestamp in the default radiotap rx code makes
> > > it not so simple anymore.
> >
> > Uh, so how am I supposed to get the timestamp? Copy all the code into
> > b43 and make it generate the exact same radiotap header? That's pretty
> > crappy too.
>
> On rt2x00, we've just added a facility that dumps information about all
> frames received and transmitted at a very low level. We dump general
> information about the frame, the tx/rx descriptors and the packet. Maybe
> something similar would also be useful for b43?
that's not a solution if you want them per packet in the radiotap header.
kismet & wireshark use them as well as other applications.
bruno
"ext Michael Wu" <[email protected]> writes:
>> This makes mac80211 include the low-level MAC timestamp
>> in the radiotap header.
>>
> No thanks. Not every driver supports reporting the timestamp and supporting
> timestamp/no timestamp in the default radiotap rx code makes it not so simple
> anymore.
Having MAC timestamps is very useful when one is debugging low level
problems. I'm currently using madwifi for this but would prefer b43.
How many drivers do not support MAC timestamps? It would be really
shame to loose this functionality.
--
Kalle Valo