Prop #8 WiFi (WPA,WPA2 encryption)

[scottmc]

Prop #8 WiFi (WPA,WPA2 encryption)

This was voted as a must-have for Haiku R1 and since a requirement for beta1 is to be feature complete, this is a beta1 blocker.

Developer results

• must-have (nielx, pulkomandy, umccullough, czeidler, jprostko, siarzhuk, jonas.kirilla, scottmc, anevilyak, 3dEyes, stippi, axeld, leavengood, mmlr, yourpalal, mmadia, oruizdorantes, colin, zooey, ithamar, korli, laplace, tqh, phoudoin, bonefish, humdinger, Wim, sikosis, brecht)
• only-if-ready none

General poll results

[scottmc]

Can we call this one complete yet?

[mmlr]

Replying to scottmc:

Can we call this one complete yet?

Technically yes, as the encryption and authentication is working with the wpa_supplicant in place. But really I'd see this one a bit broader, as in being usable conveniently in everyday scenarios. For this, storing the credentials and some form of sensible auto-connect still needs to be implemented. I'm taking ownership in any case.

[scottmc]

Replying to mmlr:

Replying to scottmc:

Can we call this one complete yet?

Technically yes, as the encryption and authentication is working with the wpa_supplicant in place. But really I'd see this one a bit broader, as in being usable conveniently in everyday scenarios. For this, storing the credentials and some form of sensible auto-connect still needs to be implemented. I'm taking ownership in any case.

How much is left to do on this? Should we add #7663 as a blocker?

[modeenf]

Replying to scottmc:

Replying to mmlr:

Replying to scottmc:

Can we call this one complete yet?

Technically yes, as the encryption and authentication is working with the wpa_supplicant in place. But really I'd see this one a bit broader, as in being usable conveniently in everyday scenarios. For this, storing the credentials and some form of sensible auto-connect still needs to be implemented. I'm taking ownership in any case.

How much is left to do on this? Should we add #7663 as a blocker?

I believe so..

[umccullough]

I think we shouldn't hold this ticket up for #7663, it doesn't make sense.

Is there anything left to implement for WPA/WPA2 specifically?

[pulkomandy]

Yes, there are a few problems left:

• Can't join network with special chars (space or so) in the SSID or key
• Network connection is unreliable and will drop after some time, without any notice.
• wpa_supplicant can be crashed easily, and isn't restarted
• if you enter the wrong key and fail connecting to a network, you have to reboot and start over

[taos]

Replying to pulkomandy:

Yes, there are a few problems left:

• Can't join network with special chars (space or so) in the SSID or key

Which special characters still can't be used in the SSID? Since alpha 4 I've been able to connect to a SSID with 2 spaces (with a key containing special characters). In recent nightlies, such a key can also be stored with the keystore manager.

[pulkomandy]

This may be ok now. I encoutered this issue back then with one of the wifi networks used at BeGeistert, and I can't test it easily here, lacking a secondary wifi AP on which I can test things. If someone has a test access point for this, it would be interesting to test:

• spaces (but as mentionned this may work now)
• special chars (quotes, *, etc)
• unicode (SSID using cyrillic or CJK characters)

Both in the SSID and in the WPA key.

[kallisti5]

#12279 -- Can't join network with special chars (space or so) in the SSID or key

[kallisti5]

#12280 -- Failing to connect to a wifi ap results in the need for a reboot.

[kallisti5]

#12281 -- wpa_supplicant can be crashed easily, and isn't restarted

[kallisti5]

As for "Network connection is unreliable and will drop after some time, without any notice.", is this still an issue? Maybe we just need a simple notification of wifi network connectivity loss?

[mmlr]

Replying to kallisti5:

As for "Network connection is unreliable and will drop after some time, without any notice.", is this still an issue? Maybe we just need a simple notification of wifi network connectivity loss?

This is generally something the wpa_supplicant is supposed to handle internally. It monitors the network interface and should react to the disassociation event. As long as the configuration isn't changed by attempting to connect to a different network, the settings and credentials the wpa_supplicant uses stay the same. It should therefore attempt to reassociate with the previous access point. I am somewhat certain that I have observed this on my network and that it worked as intended (but it's been quite a while since I actively looked so my memory might play tricks). A reproducible test case would be helpful to confirm/refute this would helpful.

An issue on the lower layers, i.e. FreeBSD compatibility and drivers, could also be at play here. A corresponding log should be gathered by running the wpa_supplicant from the terminal before attempting to connect and then connecting as usual (which should then use the already running wpa_supplicant).

[axeld]

No reason to make this blocking a release anymore.

[pulkomandy]

I think jua's change to allow disabling wifi N support fixed most of the problems on my machines. Things can still be improved but I think we could consider this ticket fixed and open more specific ones for remaining problems now?

[axeld]

Sure, actually already before that; the feature has been implemented. Eventual bugs should be handled in their own tickets.