I am experiencing problems trying to connect, idualwifi7260

[WildKeccak]

I have to be extra patient with the dialogs when connecting to my WiFi network, because there are a lot of false starts. It appears that nothing is happening, because the dialog comes back; It works for a second and then stops. Kind of like a motorcycle.

hrev53555

i5-7200U

[waddlesplash]

This problem also occurs with this driver on FreeBSD, so don't expect a resolution anytime soon.

[WildKeccak]

This might be two or more bugs. I just barely installed hrev53556 x86-64, right clicked on the network thing to the left of the audio control, selected my network (which was visible this time, thankfully). Then I entered my credentials, and waited for the dialog to come back. It then asked me to allow the key to be added to the keyring, and promptly connected.

I think the dropdown list also stops working around 300+ items. Or invalid entries, or something. I have a screenshot that I will give you

HP 15-bs070wm

[WildKeccak]

A screenshot of wifi dialog malfunction

[waddlesplash]

There is a separate ticket for that already

[WildKeccak]

There /is/ some wisdom in reformatting and reinstalling :)

[WildKeccak]

Um, waddlesplash, help me. I can't find that separate ticket.

[X512]

Replying to WildKeccak:

Um, waddlesplash, help me. I can't find that separate ticket.

This looks like same as ProcessController menu problem in #8513.

[WildKeccak]

hrev 53903 is much better?

[WildKeccak]

This ticket's predicate is no longer true. hrev53903 on same computer.

[waddlesplash]

As I said before, the problem is intermittent; sometimes the driver works better than others for no apparent reason.

[waddlesplash]

Please retest under the new wpa_supplicant under the nightlies (version 2.9).

[WildKeccak]

It's still complicated and doesn't always work consistently. I'm not seeing a difference yet. hrev54045.

[miqlas]

I have the same hw and same problem, this is what i experience:
1) Trying to join to a WLAN
2) credentials window pops up
3) I fill the password and tick the save password box, then try to connect
4) Sometimes it work, in this case no other steps necessary.
5) If it doesn't works for the first try, the password window pops up again, password already prefilled
6) I press connect again
7) credentials window pops up again after a while
8) If i open the Network preflet, i see no networks in the WLAN SSID lists, as like the network card became deaf
9) I disable the card and re-enable it in the network preflet
10) SSIDs shows up in the list again
11) Start the process over from point 5

So what i see is: the credentials box pops up, even if the network card became deaf. It just repeatedly pops up. No other sign of complete lost of the networking ability (=deaf), just the empty SSID list. I assume not everybody notices this, and just gets annoyed it doesn't connect.

But if the password once saved and while the SSID's visible in the list the password window pops sometimes still up. In this case pressing Cancel in the password window results a successful connection establishment. I use this trick daily. Hope it will help.

So i think this phenomen is a result of 2 or more bug:

- WLAN card loses ability to see the networks (=deaf, seeing no WLANs), wpa_supplicant unaware to this and trying to connect/asking for password for an unavailable network because the lost connectivity ability of the wlan card. This should not happen, but if the network goes missing Haiku maybe should try to reset the card automatically (disable/enable)
- Even if the card sees the SSID's, the connection establishment is sometimes somehow unsuccessful, and Haiku asks repeatedly for password, i don't know why it is happening. Maybe the network_server can't acquire the DHCP settings and timeouts, but i am unsure.

This happens for me with wpa_supplicant 2.7 and 2.9 too. Hope it gives some hints.

So @WildKecak, please test this: make sure the networks still listed in the network preflet (or with the network replicant) while the credentials popup visible and try to press the cancel button. (unsure about the button text, but it is on the left side of the window)

[dogcow]

I just installed R1/beta2 (hrev54154+113) and am essentially experiencing the same troubles as @miqlas, except in my case, I am never able to get my Intel 7260 to establish a connection to my home AP. (I did get it to work once on my cellular phone's hotspot).

The exact same card works fine in a myriad of Linux distros, so I believe there is a bug somewhere within Haiku or the driver pulled from FreeBSD that causes this card to fail to associate with certain APs.

/var/log/syslog dozens of deauth events for reason 1 and reason 9. I was in the process of attempting to grab a copy of the log when the kernel panicked from inserting a USB drive...so I'll attempt again later as I'm too tired now.

For the record, my home AP is an enterprise-grade Ruckus R510, and I've never had any problems connecting any devices to it before, ranging from the cheapest ESP8266 microcontrollers to Android and iOS devices and laptops running FreeBSD, OpenBSD, Linux, or Windows.

I will make an effort to install FreeBSD on this same system to see if I run into the same troubles.

[dogcow]

Here are some samples from syslog when trying to connect to my AP. Note failure codes 1 and 9.

[net/idualwifi7260/0] ieee80211_wme_updateparams_locked: WME params updated, cap_info 0x0
[net/idualwifi7260/0] ieee80211_new_state_locked: SCAN -> AUTH (nrunning 0 nscanning 0)
[net/idualwifi7260/0] ieee80211_newstate_cb: SCAN -> AUTH arg 192
[net/idualwifi7260/0] sta_newstate: SCAN -> AUTH (192)
[net/idualwifi7260/0] ieee80211_ref_node (ieee80211_send_mgmt:2463) 0xffffffffa184c000<18:7c:0b:3b:fc:0c> refcnt 3
[net/idualwifi7260/0] [18:7c:0b:3b:fc:0c] recv auth frame with algorithm 0 seq 2
[net/idualwifi7260/0] ieee80211_new_state_locked: AUTH -> ASSOC (nrunning 0 nscanning 0)
[net/idualwifi7260/0] ieee80211_newstate_cb: AUTH -> ASSOC arg 0
[net/idualwifi7260/0] sta_newstate: AUTH -> ASSOC (0)
[net/idualwifi7260/0] ieee80211_ref_node (ieee80211_send_mgmt:2463) 0xffffffffa184c000<18:7c:0b:3b:fc:0c> refcnt 3
[net/idualwifi7260/0] [18:7c:0b:3b:fc:0c] recv disassociate (reason: 1 (unspecified))
[net/idualwifi7260/0] ieee80211_new_state_locked: ASSOC -> ASSOC (nrunning 0 nscanning 0)
[net/idualwifi7260/0] ieee80211_newstate_cb: ASSOC -> ASSOC arg 0
[net/idualwifi7260/0] sta_newstate: ASSOC -> ASSOC (0)
[net/idualwifi7260/0] ieee80211_ref_node (ieee80211_send_mgmt:2463) 0xffffffffa184c000<18:7c:0b:3b:fc:0c> refcnt 3
[net/idualwifi7260/0] [18:7c:0b:3b:fc:0c] recv deauthenticate (reason: 9 (STA requesting (re)association is not authenticated))

[dogcow]

I installed FreeBSD 12.1 on the same machine I'm using Haiku on, and I can't get the Intel 7260 card to successfully connect to my AP in FreeBSD, either.

At this point, I am going to surmise that the Intel 7260 implementation is broken in FreeBSD, so it makes sense it doesn't work well in Haiku.

Off to look for another Wi-Fi card....

From FreeBSD:

wlan0: Trying to associate with xx:xx:xx:xx:xx:xx (SSID="xxxx" freq=2462 MHz)
FT: Invalid group cipher (0)
Failed to add supported operating classes IE
wlan0: Authentication with xx:xx:xx:xx:xx:xx timed out.
wlan0: CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx (SSID="xxxx" freq=2462 MHz)
wlan0: Trying to associate with xx:xx:xx:xx:xx:xx (SSID="xxxx" freq=2462 MHz)
FT: Invalid key management type (2)
Failed to add supported operating classes IE

[waddlesplash]

Please file a ticket with FreeBSD, then. I use this driver with a 7265D and a 9260 and it works great for those, so the problem may be with some other layer of the stack. The "Invalid group cipher" looks very suspicious.

[dogcow]

FreeBSD ticket: ​https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247625

[dogcow]

There seems to be an incompatibility between Haiku's wireless subsystem, which as we know is taken from FreeBSD and certain access points (Ruckus R510 Unleashed in my case). I have done extensive testing on this, and my finds are as follows.

I acquired an Atheros ATH-AR5B125 card to do some further testing.

Intel 7260 card: Haiku will not connect. FreeBSD 12 will not connect.

Atheros ATH-AR5B125 card: Haiku will not connect. FreeBSD works!

Both cards will connect to certain different APs, like my cellular phone's hotspot.

Details:

You can see the syslog events from the 7260 in my previous comment.

Now, here's a sample of Haiku's syslog with the Atheros card attempting to connect to a completely open (no password/no encryption) network:

KERN: ifmedia_ioctl: switching wlan to   Type: IEEE 802.11 Wireless Ethernet
KERN:   Mode: autoselect
KERN:   SubType: autoselect
KERN: wlan_control: 9234, 18
KERN: wlan_control: 9234, 7
KERN: wlan_control: 9234, 95
KERN: wlan_control: 9234, 17
KERN: wlan_open(0xffffffffa0114000)
KERN: [net/atheroswifi/0] ieee80211_init
KERN: [net/atheroswifi/0] start running, 1 vaps running
KERN: wlan_control: 9234, 21
KERN: [net/atheroswifi/0] [18:7c:0b:bb:fc:08] station assoc via MLME
KERN: [net/atheroswifi/0] ieee80211_alloc_node 0xffffffff9f530000<18:7c:0b:bb:fc:08> in station table
KERN: [net/atheroswifi/0] [18:7c:0b:bb:fc:08] ieee80211_alloc_node: inact_reload 2
KERN: [net/atheroswifi/0] node_reclaim: remove 0xffffffff9f560000<20:16:d8:cc:93:55> from station table, refcnt 0
KERN: [net/atheroswifi/0] set WME_AC_BE (chan) [acm 0 aifsn 3 logcwmin 4 logcwmax 10 txop 0]
KERN: [net/atheroswifi/0] set WME_AC_BE (bss ) [acm 0 aifsn 3 logcwmin 4 logcwmax 10 txop 0]
KERN: [net/atheroswifi/0] set WME_AC_BK (chan) [acm 0 aifsn 7 logcwmin 4 logcwmax 10 txop 0]
KERN: [net/atheroswifi/0] set WME_AC_BK (bss ) [acm 0 aifsn 7 logcwmin 4 logcwmax 10 txop 0]
KERN: [net/atheroswifi/0] set WME_AC_VI (chan) [acm 0 aifsn 2 logcwmin 3 logcwmax 4 txop 94]
KERN: [net/atheroswifi/0] set WME_AC_VI (bss ) [acm 0 aifsn 2 logcwmin 3 logcwmax 4 txop 94]
KERN: [net/atheroswifi/0] set WME_AC_VO (chan) [acm 0 aifsn 2 logcwmin 2 logcwmax 3 txop 47]
KERN: [net/atheroswifi/0] set WME_AC_VO (bss ) [acm 0 aifsn 2 logcwmin 2 logcwmax 3 txop 47]
KERN: [net/atheroswifi/0] update WME_AC_BE (chan+bss) [acm 0 aifsn 2 logcwmin 4 logcwmax 10 txop 64]
KERN: [net/atheroswifi/0] ieee80211_wme_updateparams_locked: WME params updated, cap_info 0x0
KERN: [net/atheroswifi/0] ieee80211_new_state_locked: SCAN -> AUTH (nrunning 0 nscanning 0)
KERN: [net/atheroswifi/0] ieee80211_newstate_cb: SCAN -> AUTH arg 192
KERN: [net/atheroswifi/0] sta_newstate: SCAN -> AUTH (192)
KERN: [net/atheroswifi/0] ieee80211_ref_node (ieee80211_send_mgmt:2463) 0xffffffff9f530000<18:7c:0b:bb:fc:08> refcnt 4
KERN: [net/atheroswifi/0] [18:7c:0b:bb:fc:08] recv auth frame with algorithm 0 seq 2
KERN: [net/atheroswifi/0] ieee80211_new_state_locked: AUTH -> ASSOC (nrunning 0 nscanning 0)
KERN: [net/atheroswifi/0] ieee80211_newstate_cb: AUTH -> ASSOC arg 0
KERN: [net/atheroswifi/0] sta_newstate: AUTH -> ASSOC (0)
KERN: [net/atheroswifi/0] ieee80211_ref_node (ieee80211_send_mgmt:2463) 0xffffffff9f530000<18:7c:0b:bb:fc:08> refcnt 4
KERN: [net/atheroswifi/0] [18:7c:0b:bb:fc:08] recv disassociate (reason: 1 (unspecified))
KERN: [net/atheroswifi/0] ieee80211_new_state_locked: ASSOC -> ASSOC (nrunning 0 nscanning 0)
KERN: [net/atheroswifi/0] ieee80211_newstate_cb: ASSOC -> ASSOC arg 0
KERN: [net/atheroswifi/0] sta_newstate: ASSOC -> ASSOC (0)
KERN: [net/atheroswifi/0] ieee80211_ref_node (ieee80211_send_mgmt:2463) 0xffffffff9f530000<18:7c:0b:bb:fc:08> refcnt 4
KERN: [net/atheroswifi/0] [18:7c:0b:bb:fc:08] recv deauthenticate (reason: 9 (STA requesting (re)association is not authenticated))
KERN: [net/atheroswifi/0] ieee80211_new_state_locked: ASSOC -> AUTH (nrunning 0 nscanning 0)
KERN: [net/atheroswifi/0] ieee80211_newstate_cb: ASSOC -> AUTH arg 2496
KERN: [net/atheroswifi/0] sta_newstate: ASSOC -> AUTH (2496)
KERN: [net/atheroswifi/0] ieee80211_ref_node (ieee80211_send_mgmt:2463) 0xffffffff9f530000<18:7c:0b:bb:fc:08> refcnt 4
KERN: [net/atheroswifi/0] [18:7c:0b:bb:fc:08] recv auth frame with algorithm 0 seq 2
KERN: [net/atheroswifi/0] ieee80211_new_state_locked: AUTH -> ASSOC (nrunning 0 nscanning 0)
KERN: [net/atheroswifi/0] ieee80211_newstate_cb: AUTH -> ASSOC arg 0
KERN: [net/atheroswifi/0] sta_newstate: AUTH -> ASSOC (0)
KERN: [net/atheroswifi/0] ieee80211_ref_node (ieee80211_send_mgmt:2463) 0xffffffff9f530000<18:7c:0b:bb:fc:08> refcnt 4
KERN: [net/atheroswifi/0] [18:7c:0b:bb:fc:08] recv disassociate (reason: 1 (unspecified))
KERN: [net/atheroswifi/0] ieee80211_new_state_locked: ASSOC -> ASSOC (nrunning 0 nscanning 0)
KERN: [net/atheroswifi/0] ieee80211_newstate_cb: ASSOC -> ASSOC arg 0
KERN: [net/atheroswifi/0] sta_newstate: ASSOC -> ASSOC (0)
KERN: [net/atheroswifi/0] ieee80211_ref_node (ieee80211_send_mgmt:2463) 0xffffffff9f530000<18:7c:0b:bb:fc:08> refcnt 4
KERN: [net/atheroswifi/0] [18:7c:0b:bb:fc:08] recv deauthenticate (reason: 9 (STA requesting (re)association is not authenticated))
KERN: [net/atheroswifi/0] ieee80211_new_state_locked: ASSOC -> AUTH (nrunning 0 nscanning 0)
KERN: [net/atheroswifi/0] ieee80211_newstate_cb: ASSOC -> AUTH arg 2496
KERN: [net/atheroswifi/0] sta_newstate: ASSOC -> AUTH (2496)
KERN: [net/atheroswifi/0] ieee80211_ref_node (ieee80211_send_mgmt:2463) 0xffffffff9f530000<18:7c:0b:bb:fc:08> refcnt 4
KERN: [net/atheroswifi/0] [18:7c:0b:bb:fc:08] recv auth frame with algorithm 0 seq 2
KERN: [net/atheroswifi/0] ieee80211_new_state_locked: AUTH -> ASSOC (nrunning 0 nscanning 0)
KERN: [net/atheroswifi/0] ieee80211_newstate_cb: AUTH -> ASSOC arg 0
KERN: [net/atheroswifi/0] sta_newstate: AUTH -> ASSOC (0)
KERN: [net/atheroswifi/0] ieee80211_ref_node (ieee80211_send_mgmt:2463) 0xffffffff9f530000<18:7c:0b:bb:fc:08> refcnt 4
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: Last message repeated 12 times.
KERN: [net/atheroswifi/0] ieee80211_new_state_locked: ASSOC -> SCAN (nrunning 0 nscanning 0)
KERN: [net/atheroswifi/0] ieee80211_newstate_cb: ASSOC -> SCAN arg 1
KERN: [net/atheroswifi/0] sta_newstate: ASSOC -> SCAN (1)
KERN: wlan_control: 9234, 21
KERN: [net/atheroswifi/0] [18:7c:0b:bb:fc:08] station deauth via MLME (reason: 3 (sending STA is leaving/has left IBSS or ESS))
KERN: [net/atheroswifi/0] ieee80211_new_state_locked: SCAN -> INIT (nrunning 0 nscanning 0)
KERN: [net/atheroswifi/0] ieee80211_newstate_cb: SCAN -> INIT arg 3
KERN: [net/atheroswifi/0] sta_newstate: SCAN -> INIT (3)
KERN: [net/atheroswifi/0] node_reclaim: remove 0xffffffff9f530000<18:7c:0b:bb:fc:08> from station table, refcnt 2
KERN: [net/atheroswifi/0] ieee80211_alloc_node 0xffffffff9f560000<20:16:d8:cc:93:55> in station table
KERN: [net/atheroswifi/0] [20:16:d8:cc:93:55] ieee80211_alloc_node: inact_reload 2

I have updated the upstream FreeBSD ticket with my findings.

[dogcow]

This may be helpful to anyone having problems with the 7260 or other cards that use the iwm driver from FreeBSD.

I learned that my access point was configured to only accept connections from clients using 802.11n or newer. The iwm driver does not support the newer protocols, and only works in 802.11b or 802.11g modes. Unfortunately, this is not currently documented in FreeBSD, so I have submitted a patch to update their man page accordingly.

Once I enabled the legacy modes on my AP, the 7260 began working as expected.

[WildKeccak]

It works, and has worked, generally speaking, for a while now.

[korli]

Please reopen if needed.