Opened 8 years ago

Closed 3 years ago

#7660 closed bug (fixed)

Prop #8 WiFi (WPA,WPA2 encryption)

Reported by: scottmc Owned by: mmlr
Priority: normal Milestone: R1/beta1
Component: Network & Internet/Wireless Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by pulkomandy)

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

Change History (25)

comment:1 Changed 8 years ago by mmadia

Description: modified (diff)

comment:2 Changed 8 years ago by scottmc

Can we call this one complete yet?

comment:3 in reply to:  2 ; Changed 8 years ago by mmlr

Owner: changed from axeld to mmlr
Status: newin-progress

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.

comment:4 in reply to:  3 ; Changed 6 years ago by 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?

comment:5 in reply to:  4 Changed 6 years ago by 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..

comment:6 Changed 6 years ago by scottmc

Blocked By: 7663 added

comment:7 Changed 5 years ago by 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?

comment:8 Changed 5 years ago by pulkomandy

Blocked By: 7663 removed

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

comment:9 Changed 5 years ago by pulkomandy

Description: modified (diff)

comment:10 in reply to:  8 Changed 4 years ago by 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.

comment:11 Changed 4 years ago by 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.

comment:12 Changed 4 years ago by kallisti5

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

comment:13 Changed 4 years ago by kallisti5

Blocked By: 12280 added

comment:14 Changed 4 years ago by kallisti5

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

comment:15 Changed 4 years ago by kallisti5

Blocked By: 12279 added

comment:16 Changed 4 years ago by kallisti5

Blocked By: 12281 added

comment:17 Changed 4 years ago by kallisti5

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

comment:18 Changed 4 years ago by 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?

comment:19 in reply to:  18 Changed 4 years ago by 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).

comment:20 Changed 3 years ago by axeld

Priority: blockernormal

No reason to make this blocking a release anymore.

comment:21 Changed 3 years ago by 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?

comment:22 Changed 3 years ago by axeld

Blocked By: 12281 removed

comment:23 Changed 3 years ago by axeld

Blocked By: 12280 removed

comment:24 Changed 3 years ago by axeld

Blocked By: 12279 removed

comment:25 Changed 3 years ago by axeld

Resolution: fixed
Status: in-progressclosed

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

Note: See TracTickets for help on using tickets.