Re: [RFA] 0-length PSDU reporting

[Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]

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