From owner-freebsd-wireless@freebsd.org Mon May 24 12:19:33 2021 Return-Path: Delivered-To: freebsd-wireless@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9B66F634190 for ; Mon, 24 May 2021 12:19:33 +0000 (UTC) (envelope-from martin@duskware.de) Received: from mail.duskware.de (mail.duskware.de [IPv6:2a00:19e0:3004:291::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fpbqm727yz4mKj for ; Mon, 24 May 2021 12:19:29 +0000 (UTC) (envelope-from martin@duskware.de) Received: by mail.duskware.de (Postfix, from userid 205) id B828AA7E8D; Mon, 24 May 2021 14:19:20 +0200 (CEST) Date: Mon, 24 May 2021 14:19:20 +0200 From: Martin Husemann To: freebsd-wireless@FreeBSD.org Subject: monitor mode APs and bpf DLTs Message-ID: <20210524121920.GA29192@mail.duskware.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-Rspamd-Queue-Id: 4Fpbqm727yz4mKj X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of martin@duskware.de has no SPF policy when checking 2a00:19e0:3004:291::144) smtp.mailfrom=martin@duskware.de X-Spamd-Result: default: False [0.20 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[martin]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:19e0:3004:291::144:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[NetBSD.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:19e0:3004:291::144:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_SPAM_SHORT(1.00)[1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[martin@NetBSD.org,martin@duskware.de]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25504, ipnet:2a00:19e0::/29, country:DE]; FROM_NEQ_ENVFROM(0.00)[martin@NetBSD.org,martin@duskware.de]; MAILMAN_DEST(0.00)[freebsd-wireless]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 12:19:33 -0000 Hey folks, I am slightly confused about the bpf details for wireless devices. First (minor nit) there is a bogus diagnostic printed by tcpdump when trying to use monitor mode (-I) for non-montior-mode VAPs. It tells me about the wrong mode VAP and claims: To create a new montior mode VAP use: ifconfig wlan1 create wlandev run0 wlanmode monitor ... which is nearly correct, but "wlan1" should be "wlan", and unfortunately run(4) does not support mulitple VAPs, so I need to destroy wlan0 first. (I tested on 12.1) But that cosmetic issue asside, I am confused whether tcpdump -I should have any effect at all (and if not, whether it would be better to just reject the request). My understanding was that a VAP in monitor mode automatically (and exclusively) will provide IEEE802_11_RADIO type frames (i.e. with radiotap header via the iv_rawbpf tap, and plain ethernet frames via the default tap), while a VAP in any other mode will only/exclusively provide IEEE802_11 type frames (i.e. w/o radiotap header). There is no difference in tcpdump -L output with or without -I, and also no difference for "wlandmode monitor" and other mode VAPs. I expected no difference with -I vs. no -I, but I did expect a difference between a monitor mode VAP and a VAP in other modes. So I guess I am missing some part of the picture - any hints? Martin