From owner-freebsd-wireless@freebsd.org Sat Aug 4 22:32:34 2018 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3D3A1055E0A for ; Sat, 4 Aug 2018 22:32:34 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5DE358C32A for ; Sat, 4 Aug 2018 22:32:34 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id d9-v6so12914029itf.2 for ; Sat, 04 Aug 2018 15:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JOrqKyz16VVVpkt5nHaH5/T5dhgv6LC3wzFzxGfu86Q=; b=R0+QySNLeJ7TbjtMCSRip9yI2rILgvXgBTBZQC3SCHnGK0qst8wXGmAWUem9G64n6K BPILlYwQKok/u0yxy+QUlLZWxDnYy4mCp1Fmf+8HXOs8+E1IGGWBWl3BjE82opyTyhAs eN2J+u7OOUECQtDLTF/+4/kTNRlqeyX2jd4JnmsWWoqa1dcD/b/oMUIZeLCt0xQ2D/Zs buSeR7dy4zv+hEDHxQJSmhnv0x46/8+BJ2BogAx2a6egYNqhAdxwM9VzJmf+Exenkh0+ BspNdaBv6MhrQSNt7MAgYLjkMnREllA2nyYtjG845GKJonX/c0nSa5rsXhs1ZqdLjAjq 4Peg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JOrqKyz16VVVpkt5nHaH5/T5dhgv6LC3wzFzxGfu86Q=; b=kA3onHbPpQIh1RtuI72A7dKu0C2q+1Thkh8hdvfmD/Vo9qokersn7V6l2WWZv61s7s rdYL75DJOYhIde3QWB2X1LsdyXdqtI+4ZdBbxsAPuymwaKyjb19eya/6fZzudonv9HEo kraMi0wriRbS6hrg/I75ZhidMTdcV84SH2lnt3gojXwxXRuErtzAnEFwthHUTszucA4F Y/aLV3Oil3VcEAzgP/aC9Y9cbb+amxCjjt2U4mM5Vpy7xgaDKmry8k8Og3/ja8j8LTIm HoT4AaSVS8BkkDOk9m6z7Aq1vpVITrMx8UAYGQGihFCknkmiVLb1mJF1q67m7EZvHGzv lFxw== X-Gm-Message-State: AOUpUlGpa/nXou0zrQ1+qNx5tEm7VYqX7CL0ImUF667z6PoEX/UXLOYk fqqFf/teMB9UyZq5BbOrWj6FVAJVi++n4SmElPrBxy0Jlg4= X-Google-Smtp-Source: AAOMgpfQghywfPe/0AzaPltRwfiBZo6iRBOn167d0X42xXeQ/B/N/oeSOrLz9ckhDTbA1oY+jq/kafMNhP1bYPRIF7E= X-Received: by 2002:a24:f545:: with SMTP id k66-v6mr10770854ith.138.1533421953498; Sat, 04 Aug 2018 15:32:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac0:8101:0:0:0:0:0 with HTTP; Sat, 4 Aug 2018 15:32:13 -0700 (PDT) From: Farhan Khan Date: Sat, 4 Aug 2018 18:32:13 -0400 Message-ID: Subject: Where do monitor mode and STA mode begin to differ? To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.27 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: Sat, 04 Aug 2018 22:32:35 -0000 Hi all, Is there anything in net80211(4)'s initialization that is different between STA and monitor mode, specially around Rx? Short explanation: My extension to rtwn(4)'s monitor mode works, I can see arbitrary frames with tcpdump, but STA mode does not receive anything except the probe requests it sends out itself. Every 30 seconds in STA mode I get this: "rtwn0: device timeout" and the device re-initializes. I suspect this is due to it not receiving any frames. What might be initializing differently depending on if its STA or Monitor mode? If I can find where that is, I might be able to make an adjustment. I do not see anything that stands out in rtwn(4)'s init sequence, but I'll give it another look. Is there anything in net80211(4) that happens different based on the mode of the vap? Verbose explanation: As Adrian suggested on IRC, I went through rtwn_scan_start and rtwn_scan_end. This matched the Linux code. All these lines did, however, was adjust the Rx filter to receive beacons/probes from any BSSID, then uses ieee80211's probe functions to send out probe requests for whatever the VAP's ssid is set to. Running "tcpdump -ni wlan0 -y IEEE802_11_RADIO" **only** shows probes from what the device is sending and dtrace probes do not show the net80211(4) functions you would expect to happen to classify the frame. On a separate device, I monitored for frames and saw the Probe requests and responses to and from a test AP I setup, followed by an empty probe requests, which is exactly what ieee80211_swscan_probe_curchan() does. So Tx works. Great! rtwn(4) performs filter initialization in rtwn_rxfilter_init(). I checked that code to see if anything was being filtered that should not and nothing stood out to me. I unfiltered everything using rtwn_write_2(sc, R92C-RXFLTMAP0/1/2, 0xffff), and #IFDEF 0'd out the entire function. Same result. I should also note that rtwn_rxfilter_init() is used by every rtwn(4) device and is probably standard for this Realtek series. This suggests to me that somewhere during the initialization STA fails. Again, I will look through rtwn(4)'s init sequence, but is there anything in ieee80211(4) that might be different depending on if its in monitor mode or STA mode? And if you don't know, can you kindly guide me to what net80211(4) function first discriminates between the device mode? Thank you and I apologize for the long email. -- Farhan Khan PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE