Bug 247625
| Summary: | Intel 7260 (iwm) will not connect to access point | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Charles Ross <cwr> |
| Component: | wireless | Assignee: | Adrian Chadd <adrian> |
| Status: | Closed Works As Intended | ||
| Severity: | Affects Some People | CC: | adrian |
| Priority: | --- | ||
| Version: | 12.1-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
| Attachments: | |||
|
Description
Charles Ross
2020-06-28 22:32:02 UTC
Anecdotally, I've seen a similar issue with a router (TP-Link Archer C7 v2) running OpenWRT 19.07 built with the new (default?) ath79 target. I was unable to get a connection with WPA2-PSK encryption, but connections succeeded when using a different cipher/encryption scheme (TKIP instead of AES? maybe WPA1?). Intel Wireless 8265, FreeBSD 12.1-RELEASE. I should report this on the OpenWrt bug tracker, just mentioning it here in case your situation is similar. I have done some additional testing both in Haiku and in FreeBSD. I acquired an Atheros AR5B125 card, which experiences the exact same issues under Haiku (it will not connect to the AP). One important thing to note is that it refuses to connect regardless of if the AP is set up to require WPA2 or if the AP is completely open with no auth/encryption. When booted into FreeBSD, unlike the 7260 (which does not work in FreeBSD, either), the AR5B125 works just fine, both on open and WPA2 SSIDs. My understanding is that Haiku does have its own port of wpa_supplicant, but for "open" connections, Haiku relies solely on FreeBSD's Wi-Fi stack essentially without modifications. This seems to be some kind of fundamental incompatibility between the drivers and the access point (Ruckus R510 Unleashed, latest firmware). I am able to make these cards connect to other access points, such as my mobile phone's hotspot. While it is possible that the problem may lay with the AP itself, given that it is an enterprise-grade unit, and that I have successfully been able to connect dozens of other devices and OSes to it without an issue (only the FreeBSD/Haiku drivers have given me trouble), I suspect that the AP is probably not at fault. I am happy to provide additional information if you need specifics, please let me know what I can do. hi! under freebsd please run wpa_supplicant.conf with '-ddd'on the command line and in the foreground; it'll run with a LOT of debugging. Please also include your wpa_supplicant.conf file here. Also if you can include the output of "ifconfig -v wlan0 list scan" it'll at least show me what the beacon IE fields are so I can see what kind of capabilities the AP is advertising. (And if someone wants to shout me one of these $300 APs I'll add it for testing here. :-) Created attachment 216227 [details]
My wpa_supplicant.conf file
Created attachment 216228 [details]
Output of wpa_supplicant -ddd
Created attachment 216229 [details]
Output of `ifconfig -v wlan0 list scan`
(In reply to Adrian Chadd from comment #3) Hi Adrian, Thank you for looking at this. I have uploaded attachments with the outputs you requested. Happy to provide anything else you need (sadly I don't have a spare AP to send you!) Comment on attachment 216228 [details]
Output of wpa_supplicant -ddd
wlan0: State: SCANNING -> ASSOCIATING
Limit connection to BSSID 18:7c:0b:bb:fc:08 freq=2462 MHz based on scan results (bssid_set=0 wps=0)
wpa_driver_bsd_associate: ssid 'bsdtest' wpa ie len 22 pairwise 16 group 16 key mgmt 2
wpa_driver_bsd_set_drop_unencrypted: enabled=1
bsd_set_opt_ie: set WPA+RSN ie (len 22)
wpa_driver_bsd_associate: set PRIVACY 1
wlan0: Setting authentication timeout: 10 sec 0 usec
Not configuring frame filtering - BSS 00:00:00:00:00:00 is not a Hotspot 2.0 network
EAPOL: External notification - EAP success=0
EAPOL: External notification - EAP fail=0
EAPOL: External notification - portControl=Auto
wlan0: Authentication with 18:7c:0b:bb:fc:08 timed out.
Added BSSID 18:7c:0b:bb:fc:08 into blacklist
... assoc is timing out. Hm!
The AP looks fine to me. It is announcing all the rates fine too. It also looks close enough so unless you don't have antennas hooked up right it isn't likely a signal level issue! Can you recompile kernel/modules with IEEE80211_DEBUG, and then do this before running wpa_supplicant: wlandebug -i wlan0 +auth +assoc +rate Thanks! Created attachment 216267 [details]
Output of wpa_supplicant after `wlandebug -i wlan0 +auth +assoc +rate`
It seems IEEE80211_DEBUG is already enabled in the GENERIC kernel, so I didn't need to re-build. This output doesn't look wildly different to me from what I previously supplied, so let me know if you need something else. Thanks!
oh! Sorry, check "dmesg" or /var/log/messages ; this stuff is being dumped into the kernel log! oh! Sorry, check "dmesg" or /var/log/messages ; this stuff is being dumped into the kernel log! (In reply to Adrian Chadd from comment #12) Well, I'm not sure what's going on. I am not getting any additional output appended to `dmesg` or /var/log/messages after turning on wlandebug and starting wpa_supplicant. hi! That's er, weird. Which version of FreeBSD is this? Yeah, -HEAD has IEEE80211_DEBUG defined, but I don't know about the release versions and I don't have 12.x installed anywhere right now. :-) You need to do wlandebug before running wpa_supplicant though! hi! That's er, weird. Which version of FreeBSD is this? Yeah, -HEAD has IEEE80211_DEBUG defined, but I don't know about the release versions and I don't have 12.x installed anywhere right now. :-) You need to do wlandebug before running wpa_supplicant though! (In reply to Adrian Chadd from comment #15) FreeBSD 12.1-RELEASE-p6. Yep, I run the wlandebug command first, before wpa_supplicant is run. It gives me the following output, which I think indicates its working. If debugging wasn't enabled in the kernel, my understanding is it would complain at this point: root@nuc-fbsd:~ # wlandebug -i wlan0 +auth +assoc +rate net.wlan.0.debug: 0xc00020<assoc,auth,rate> Created attachment 216275 [details]
Output in /var/log/messages after enabling `wlandebug`
Please accept my sincere apologies; I am clearly operating on insufficient sleep and/or caffeine.
Here is the output you've requested!
Comment on attachment 216275 [details]
Output in /var/log/messages after enabling `wlandebug`
OK, this is confusing. I think i need access to the AP or the station box to do some debugging on; we shouldn't be immediately disassociated like this in a loop.
is it possible to get remote root access to this host so I can fiddle? Bonus points if we can debug on the Atheros NIC instead of iwm first. ok, so after digging into it, and using "sysctl dev.iwm.0.debug=0x2001" to enable rate and transmit debugging in iwm, I found that iwm WAS sending 11b and 11g frames to the AP ok, and they were being ACKed. Then we'd be dropped off. So then I asked Charles if his AP had legacy clients disabled, and low and behold, it did! ath(4) works on freebsd because 11n is enabled by default on it, but iwm doesn't because it only does 11abg. Once he disabled that option iwm worked fine on FreeBSD. He'll try it all out on Haiku and report back. Thank you Adrian! The Intel 7260 is indeed now working on FreeBSD and Haiku. I have opened a bug (#247874) and submitted a diff for the iwm.4 man page to include a blurb stating that iwm only supports 802.11b/g. ^Triage: assign to committer. Apparently this was solved by a configuration change. |
