[RFC] 0-length PPDU reporting

[RFC] 0-length PPDU reporting

[Johannes Berg]

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

Re: [RFC] 0-length PPDU reporting

[Simon Barber]

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

Re: [RFC] 0-length PPDU reporting

[Johannes Berg]

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

Re: [RFC] 0-length PPDU reporting

[Guy Harris]

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.

Re: [RFC] 0-length PPDU reporting

[Guy Harris]

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.

Re: [RFC] 0-length PPDU reporting

[Johannes Berg]

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

Re: [RFC] 0-length PPDU reporting

[Johannes Berg]

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 |

Re: [RFC] 0-length PPDU reporting

[Johannes Berg]

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

[RFA] 0-length PSDU reporting

[Johannes Berg]

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 |

Re: [RFA] 0-length PSDU reporting

[Guy Harris]

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.

Re: [RFA] 0-length PSDU reporting

[Johannes Berg]

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

Re: [RFA] 0-length PSDU reporting

[Johannes Berg]

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

[ADOPTION] 0-length PSDU reporting

[Johannes Berg]

---
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 |