RadioTap Archive on lore.kernel.org
 help / color / Atom feed
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
Cc: radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org
Subject: Re: [RFA] 0-length PSDU reporting
Date: Mon, 13 Aug 2018 12:35:37 +0200
Message-ID: <1534156537.3093.7.camel@sipsolutions.net> (raw)
In-Reply-To: <AEBBAD8F-A779-4E0A-B40D-659D55DFE847-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>

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

  parent reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
     [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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1534156537.3093.7.camel@sipsolutions.net \
    --to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
    --cc=guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org \
    --cc=radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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 radiotap@archiver.kernel.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