RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* [RFC] 0-length PPDU reporting
@ 2018-06-18 14:37 Johannes Berg
       [not found] ` <1529332670.3490.50.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  0 siblings, 1 reply; 13+ messages in thread
From: Johannes Berg @ 2018-06-18 14:37 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

Hi,

With HE in particular, but also previously, there are PPDUs that don't
carry any MAC header, for example sounding frames.

It seems useful to report these up, but they cause wireshark to display
an error since it's expecting to be able to decode the remainder of the
data after radiotap as an 802.11 frame.

To fix that, and to be able to show the type of PPDU, I think we should
add a new field, that contains just a 16-bit value (or 8? or even 32
since we often need more alignment anyway?) indicating the type of 0-
length PPDU.

Does anyone happen to have a more comprehensive list of PPDUs that are
like this?

johannes

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

* Re: [RFC] 0-length PPDU reporting
       [not found] ` <1529332670.3490.50.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2018-06-18 16:05   ` Simon Barber
       [not found]     ` <00986C20-9443-40FC-9A7E-DE636A743951-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
  2018-07-02 14:33   ` Johannes Berg
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 13+ messages in thread
From: Simon Barber @ 2018-06-18 16:05 UTC (permalink / raw)
  To: Johannes Berg; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

Some chipsets will also report particular types of noise as a special PPDU - used for radar detection - it might be nice to allow these as well.

Simon


> On Jun 18, 2018, at 7:37 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> 
> Hi,
> 
> With HE in particular, but also previously, there are PPDUs that don't
> carry any MAC header, for example sounding frames.
> 
> It seems useful to report these up, but they cause wireshark to display
> an error since it's expecting to be able to decode the remainder of the
> data after radiotap as an 802.11 frame.
> 
> To fix that, and to be able to show the type of PPDU, I think we should
> add a new field, that contains just a 16-bit value (or 8? or even 32
> since we often need more alignment anyway?) indicating the type of 0-
> length PPDU.
> 
> Does anyone happen to have a more comprehensive list of PPDUs that are
> like this?
> 
> johannes

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

* Re: [RFC] 0-length PPDU reporting
       [not found]     ` <00986C20-9443-40FC-9A7E-DE636A743951-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
@ 2018-06-18 19:20       ` Johannes Berg
       [not found]         ` <1529349637.3092.8.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  0 siblings, 1 reply; 13+ messages in thread
From: Johannes Berg @ 2018-06-18 19:20 UTC (permalink / raw)
  To: Simon Barber; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Mon, 2018-06-18 at 09:05 -0700, Simon Barber wrote:
> Some chipsets will also report particular types of noise as a special
> PPDU - used for radar detection - it might be nice to allow these as
> well.

Yeah, I guess we could define plenty of subtypes for these, and then you
can include all kinds of metadata you want.

These are somewhat less useful because you have less metadata, you
haven't even decoded any preambles in those cases, and you probably have
a ton of them if enabled, but sure, why not.

I'll try to build a list I guess, to come up with a proposal.

A wireshark patch should be pretty simple, just don't call through to
the 802.11 dissector?

johannes

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

* Re: [RFC] 0-length PPDU reporting
       [not found]         ` <1529349637.3092.8.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2018-06-19 21:20           ` Guy Harris
       [not found]             ` <3028EC8F-6CFD-4F52-8349-D49B1F37AC22-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
  0 siblings, 1 reply; 13+ messages in thread
From: Guy Harris @ 2018-06-19 21:20 UTC (permalink / raw)
  To: Johannes Berg; +Cc: Simon Barber, radiotap-S783fYmB3Ccdnm+yROfE0A

On Jun 18, 2018, at 12:20 PM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:

> A wireshark patch should be pretty simple, just don't call through to
> the 802.11 dissector?

Yes, although if it has radio information you should call through to the "802.11 radio" dissector (so that it shows the radio information in a pseudo-header-independent format) and pass along information to let it know that *it* shouldn't call through to the 802.11 frame dissector.

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

* Re: [RFC] 0-length PPDU reporting
       [not found]             ` <3028EC8F-6CFD-4F52-8349-D49B1F37AC22-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
@ 2018-06-19 22:50               ` Guy Harris
       [not found]                 ` <BC6DCA08-4049-4B7A-A7C0-9FC545173FE5-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
  0 siblings, 1 reply; 13+ messages in thread
From: Guy Harris @ 2018-06-19 22:50 UTC (permalink / raw)
  To: Johannes Berg; +Cc: Simon Barber, radiotap-S783fYmB3Ccdnm+yROfE0A

On Jun 19, 2018, at 2:20 PM, Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> wrote:

> On Jun 18, 2018, at 12:20 PM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> 
>> A wireshark patch should be pretty simple, just don't call through to
>> the 802.11 dissector?
> 
> Yes, although if it has radio information you should call through to the "802.11 radio" dissector (so that it shows the radio information in a pseudo-header-independent format) and pass along information to let it know that *it* shouldn't call through to the 802.11 frame dissector.

Tcpdump would also need to be changed not to call ieee802_11_print() at the end of ieee802_11_radio_print() in print-802_11.c - just return "len" for 0-length PPDUs.

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

* Re: [RFC] 0-length PPDU reporting
       [not found]                 ` <BC6DCA08-4049-4B7A-A7C0-9FC545173FE5-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
@ 2018-06-29 10:49                   ` Johannes Berg
  0 siblings, 0 replies; 13+ messages in thread
From: Johannes Berg @ 2018-06-29 10:49 UTC (permalink / raw)
  To: Guy Harris; +Cc: Simon Barber, radiotap-S783fYmB3Ccdnm+yROfE0A

On Tue, 2018-06-19 at 15:50 -0700, Guy Harris wrote:
> On Jun 19, 2018, at 2:20 PM, Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> wrote:
> 
> > On Jun 18, 2018, at 12:20 PM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> > 
> > > A wireshark patch should be pretty simple, just don't call through to
> > > the 802.11 dissector?
> > 
> > Yes, although if it has radio information you should call through to
> > the "802.11 radio" dissector (so that it shows the radio information
> > in a pseudo-header-independent format) and pass along information to
> > let it know that *it* shouldn't call through to the 802.11 frame
> > dissector.
> 
> Tcpdump would also need to be changed not to call ieee802_11_print()
> at the end of ieee802_11_radio_print() in print-802_11.c - just return
> "len" for 0-length PPDUs.

Yes, both good points. Thanks!

johannes

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

* Re: [RFC] 0-length PPDU reporting
       [not found] ` <1529332670.3490.50.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  2018-06-18 16:05   ` Simon Barber
@ 2018-07-02 14:33   ` Johannes Berg
       [not found]     ` <1530542000.3117.4.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  2018-07-09  8:30   ` [RFA] 0-length PSDU reporting Johannes Berg
  2018-09-04 12:10   ` [ADOPTION] " Johannes Berg
  3 siblings, 1 reply; 13+ messages in thread
From: Johannes Berg @ 2018-07-02 14:33 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

So, does anyone have anything else needed here?

---
title: 0-length-PPDU
categories: [suggested]
---
Bit Number
: 26 (tentatively assigned, field data may change)

Structure
  - u8 type

Required Alignment
: None

Unit(s)
: none

The presence of this field indicates that there was no PSDU in this
PPDU,
only the PHY data is valid and the radiotap header is not followed by an
802.11 header.

The type field indicates the type of PPDU.

| **type value** | **meaning** |
| 0              | sounding PPDU |
| 0xff           | vendor-specific |

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

* Re: [RFC] 0-length PPDU reporting
       [not found]     ` <1530542000.3117.4.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2018-07-03 12:13       ` Johannes Berg
  0 siblings, 0 replies; 13+ messages in thread
From: Johannes Berg @ 2018-07-03 12:13 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

On Mon, 2018-07-02 at 16:33 +0200, Johannes Berg wrote:
> So, does anyone have anything else needed here?
> 
> ---
> title: 0-length-PPDU
> categories: [suggested]
> ---
> Bit Number
> : 26 (tentatively assigned, field data may change)
> 
> Structure
>   - u8 type
> 
> Required Alignment
> : None
> 
> Unit(s)
> : none
> 
> The presence of this field indicates that there was no PSDU in this
> PPDU,
> only the PHY data is valid and the radiotap header is not followed by an
> 802.11 header.
> 
> The type field indicates the type of PPDU.
> 
> > **type value** | **meaning** |
> > 0              | sounding PPDU |
> > 0xff           | vendor-specific |

We should add here

| 1 | data not captured |

e.g. for multi-user frames that we weren't configured to capture, etc.

johannes

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

* [RFA] 0-length PSDU reporting
       [not found] ` <1529332670.3490.50.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  2018-06-18 16:05   ` Simon Barber
  2018-07-02 14:33   ` Johannes Berg
@ 2018-07-09  8:30   ` Johannes Berg
       [not found]     ` <1531125042.3298.5.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  2018-09-04 12:10   ` [ADOPTION] " Johannes Berg
  3 siblings, 1 reply; 13+ messages in thread
From: Johannes Berg @ 2018-07-09  8:30 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

So, since there were no comments - here's a proper RFA.

I'll be on vacation and then bonding leave soon, but should hopefully
manage to see this through.

(fixed title PPDU -> PSDU)


---
title: 0-length-PSDU
categories: [suggested]
---
Bit Number
: 26

Structure
  - u8 type

Required Alignment
: None

Unit(s)
: none

The presence of this field indicates that there was no PSDU in or
captured for this PPDU, only the PHY data is valid and the radiotap
header is not followed by an 802.11 header.

The type field indicates the type of PPDU.

| **type value** | **meaning** |
| 0              | sounding PPDU |
| 1              | data not captured (e.g. multi-user PPDU) |
| 0xff           | vendor-specific |

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

* Re: [RFA] 0-length PSDU reporting
       [not found]     ` <1531125042.3298.5.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2018-08-09  1:53       ` Guy Harris
       [not found]         ` <AEBBAD8F-A779-4E0A-B40D-659D55DFE847-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
  0 siblings, 1 reply; 13+ messages in thread
From: Guy Harris @ 2018-08-09  1:53 UTC (permalink / raw)
  To: Johannes Berg; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Jul 9, 2018, at 1:30 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:

> The presence of this field indicates that there was no PSDU in or
> captured for this PPDU, only the PHY data is valid and the radiotap
> header is not followed by an 802.11 header.

Would the lack of any packet data, according to the appropriate packet length field (length field in the pcap per-packet header, Original Packet Length field in pcapng packet blocks, etc.), i.e. the packet length and the radiotap header length are equal, be sufficient to indicate that?

If so, should this be renamed to "0-length PSDU type"; if absent, the packet is a 0-length PSDU of unknown type?

Or could some 802.11 chip, when running in monitor mode, provide a packet with radio information and no 802.11 header or data on certain radio-layer error conditions?  If so, that means that an explicit indication is required.

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

* Re: [RFA] 0-length PSDU reporting
       [not found]         ` <AEBBAD8F-A779-4E0A-B40D-659D55DFE847-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
@ 2018-08-13 10:35           ` Johannes Berg
       [not found]             ` <1534156537.3093.7.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  0 siblings, 1 reply; 13+ messages in thread
From: Johannes Berg @ 2018-08-13 10:35 UTC (permalink / raw)
  To: Guy Harris; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Wed, 2018-08-08 at 18:53 -0700, Guy Harris wrote:
> On Jul 9, 2018, at 1:30 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> 
> > The presence of this field indicates that there was no PSDU in or
> > captured for this PPDU, only the PHY data is valid and the radiotap
> > header is not followed by an 802.11 header.
> 
> Would the lack of any packet data, according to the appropriate packet
> length field (length field in the pcap per-packet header, Original
> Packet Length field in pcapng packet blocks, etc.), i.e. the packet
> length and the radiotap header length are equal, be sufficient to
> indicate that?

I think it's not sufficient.

> If so, should this be renamed to "0-length PSDU type"; if absent, the
> packet is a 0-length PSDU of unknown type?
> 
> Or could some 802.11 chip, when running in monitor mode, provide a
> packet with radio information and no 802.11 header or data on certain
> radio-layer error conditions?  If so, that means that an explicit
> indication is required.

Yes, one case for example is when you know the packet metadata because
you received it, but were unable to capture the data because it was a
multi-user transmission to a different user, or because it was a multi-
user transmission with more streams than you have RX chains, e.g. In
this case I'm not even sure you know the real length of the packet, to
be able to indicate it in the "Original Packet Length" field.

Additionally, I'm not sure it's possible to indicate an "Original Length
Field" all the way through from the kernel while capturing, I believe
only tcpdump/etc. will set this to long than the data frame from the
kernel when they explicitly truncate data.

johannes

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

* Re: [RFA] 0-length PSDU reporting
       [not found]             ` <1534156537.3093.7.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2018-08-14  8:30               ` Johannes Berg
  0 siblings, 0 replies; 13+ messages in thread
From: Johannes Berg @ 2018-08-14  8:30 UTC (permalink / raw)
  To: Guy Harris; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Mon, 2018-08-13 at 12:35 +0200, Johannes Berg wrote:

> Yes, one case for example is when you know the packet metadata because
> you received it, but were unable to capture the data because it was a
> multi-user transmission to a different user, or because it was a multi-
> user transmission with more streams than you have RX chains, e.g. In
> this case I'm not even sure you know the real length of the packet, to
> be able to indicate it in the "Original Packet Length" field.
> 
> Additionally, I'm not sure it's possible to indicate an "Original Length
> Field" all the way through from the kernel while capturing, I believe
> only tcpdump/etc. will set this to long than the data frame from the
> kernel when they explicitly truncate data.

To clarify - I think this field will also be used (and I think that
should be valid) when you have a PPDU that did carry a PSDU, but you
don't know its length, and thus report

  frame length == captured length == radiotap header length.

Like I said, I don't currently see a way to - at least on Linux - report
frame length > captured length. Looking at libpcap's pcap-linux.c, we
see

        caplen = packet_len;
        if (caplen > handle->snapshot)
                caplen = handle->snapshot;

We do get packet_len as recvmsg(..., MSG_TRUNC), but inside the kernel
we cannot represent a message as simply not having the data and getting
truncated even without MSG_TRUNC, so that we can't actually get out of
recvmsg() with a packet_len bigger than the in-kernel buffer.

Guy, does that address your question sufficiently?

johannes

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

* [ADOPTION] 0-length PSDU reporting
       [not found] ` <1529332670.3490.50.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
                     ` (2 preceding siblings ...)
  2018-07-09  8:30   ` [RFA] 0-length PSDU reporting Johannes Berg
@ 2018-09-04 12:10   ` " Johannes Berg
  3 siblings, 0 replies; 13+ messages in thread
From: Johannes Berg @ 2018-09-04 12:10 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

---
title: 0-length-PSDU
categories: [suggested]
---
Bit Number
: 26

Structure
  - u8 type

Required Alignment
: None

Unit(s)
: none

The presence of this field indicates that there was no PSDU in or
captured for this PPDU, only the PHY data is valid and the radiotap
header is not followed by an 802.11 header.

The type field indicates the type of PPDU.

| **type value** | **meaning** |
| 0              | sounding PPDU |
| 1              | data not captured (e.g. multi-user PPDU) |
| 0xff           | vendor-specific |

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

end of thread, back to index

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-18 14:37 [RFC] 0-length PPDU reporting Johannes Berg
     [not found] ` <1529332670.3490.50.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-06-18 16:05   ` Simon Barber
     [not found]     ` <00986C20-9443-40FC-9A7E-DE636A743951-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2018-06-18 19:20       ` Johannes Berg
     [not found]         ` <1529349637.3092.8.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-06-19 21:20           ` Guy Harris
     [not found]             ` <3028EC8F-6CFD-4F52-8349-D49B1F37AC22-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2018-06-19 22:50               ` Guy Harris
     [not found]                 ` <BC6DCA08-4049-4B7A-A7C0-9FC545173FE5-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2018-06-29 10:49                   ` Johannes Berg
2018-07-02 14:33   ` Johannes Berg
     [not found]     ` <1530542000.3117.4.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-07-03 12:13       ` Johannes Berg
2018-07-09  8:30   ` [RFA] 0-length PSDU reporting Johannes Berg
     [not found]     ` <1531125042.3298.5.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-08-09  1:53       ` Guy Harris
     [not found]         ` <AEBBAD8F-A779-4E0A-B40D-659D55DFE847-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2018-08-13 10:35           ` Johannes Berg
     [not found]             ` <1534156537.3093.7.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-08-14  8:30               ` Johannes Berg
2018-09-04 12:10   ` [ADOPTION] " Johannes Berg

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 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/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git