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, 0x), 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"
