On Sat, Aug 4, 2018 at 6:48 PM, Adrian Chadd <adrian.ch...@gmail.com> 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 <kha...@gmail.com> 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-unsubscr...@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 _______________________________________________ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
