From owner-freebsd-wireless@freebsd.org Tue Aug 14 01:48:14 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 4F0C01060E56 for ; Tue, 14 Aug 2018 01:48:14 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 DA5607768F for ; Tue, 14 Aug 2018 01:48:13 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-it0-x244.google.com with SMTP id d9-v6so16133325itf.2 for ; Mon, 13 Aug 2018 18:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JJs8OiIUgAAIC2zw7aaOch411+gKpITRv+TUlMOi8ng=; b=CxzjbGeRzZuj8KT8QqTaERMurnnXIor7jovW2S61iGrak+Xb2EGrga+gaZWuAqfQw8 qCJGzw7T0tgQBxoe08kwg9ZBtk9Mr5ImgwRcW9OmnX2+72FZnEnEWF04fzzcL9CBVdr2 AryTfye7PtsKlhjy7PRYs3W+zoJVQkUuxXcvLa+GV5Bcpc+2eaxsKKlOYa21U1FYfL4l 8Az1GzJfpvsUL3Xd6bZTeyKivkDYlwgFo/YAbyhRsXdwl0Ty86heuecEe/cA2WgkAo5b KOOCcDsOdXpbv9bVLofXdnzWMuGo9PINkawjIaWtXDdorgm4v0exT6+K1j4yOLCyCy0a eOXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JJs8OiIUgAAIC2zw7aaOch411+gKpITRv+TUlMOi8ng=; b=Mg8QItY3je3tx6KC8bH4BSvIEsXa4e44gPlAyaF1sifS4NTKdl71ZHhR1OA0TVhO0A FMpQRA8xAHfjFSidveRRRko2MtUfUP0uG2DvW9s0ux149pIwU3sNcY6lt6jTavO+gXrl h/P8Ujjy1D6kA38JgawfxXL9h69UyIZefC79MOD6VRkIelQO6i5GE0ChaEV0nlUiCDZ0 e0E8w8Ji8XZZj4ZVRO7S9g/Mf6+wW05GYJJSNqiLm52tWpAeN8IYib44RBBRg80jHSBM 9jWh3j8cBwRC5OIXaH6/t4RM1Y0Qto5AcPHU0IFhkJI4MZFV9y0K5Ym5Gwt0Fgq9u+Ca FaCg== X-Gm-Message-State: AOUpUlHwVfpSv6T93E35MC/XBuBu+aS41QKtvAJ0VHmGz6B83Kj1Qr04 1TEvqHpb+Lm2XbqNiMwfhsekQrJlnDHe8ESn/Us= X-Google-Smtp-Source: AA+uWPxf+EpyvDWZOy6P41TZeeImW1LwbOi5mCHToZnHh3eSVrFha5V5N1g+ij7P99dGbIHBh/QK4bQEZ3dpJthPKvE= X-Received: by 2002:a02:5549:: with SMTP id e70-v6mr17359159jab.20.1534211293094; Mon, 13 Aug 2018 18:48:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac0:8101:0:0:0:0:0 with HTTP; Mon, 13 Aug 2018 18:47:52 -0700 (PDT) In-Reply-To: References: From: Farhan Khan Date: Mon, 13 Aug 2018 21:47:52 -0400 Message-ID: Subject: Re: Where do monitor mode and STA mode begin to differ? To: Adrian Chadd Cc: "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: Tue, 14 Aug 2018 01:48:14 -0000 On Sat, Aug 4, 2018 at 6:48 PM, Adrian Chadd wrote: > hi! > > So, net80211 itself shouldn't really differ that much for this particular > issue. There may be some functions that aren't called in monitor mode (like > sta_join) but you're not yet there.s > > I'd look at the difference in the driver VAP setup and the newstate function > for different operating modes. If RX works in monitor mode but it's not > working in scanning mode then I'd look at how the hardware is programmed in > STA versus monitor mode. Eg, there may not be a BSS Mask programmed in for > monitor mode, or it's programmed to something like "all bits." > > > > -adrian > > > On Sat, 4 Aug 2018 at 15:32, Farhan Khan wrote: >> >> 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 >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to >> "freebsd-wireless-unsubscribe@freebsd.org" Hi Adrian, To follow-up on this, nothing uniquely stuck out to me as in rtwn_newstate. I ended up being swiching around rtwn_newstate() and rtwn_monitor_newstate() and I still was not able to receive frames while in STA mode. I'm stuck, I do not know how to proceed. I have traced the code, but do not see a differences. What else happens when you switch the device into STA mode? Thanks, -- Farhan Khan PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE