Re: [RFA] 0-length PSDU reporting
Johannes Berg <[email protected]> Tue, 14 Aug 2018 10:30:04 +0200
| Newsgroups | org.netbsd.radiotap |
|---|---|
| Message-ID | <[email protected]> |
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