#12280 closed bug (fixed)
Failing to connect to a wifi ap results in the need for a reboot.
Reported by: | kallisti5 | Owned by: | nobody |
---|---|---|---|
Priority: | blocker | Milestone: | R1/beta2 |
Component: | Network & Internet/Wireless | Version: | R1/Development |
Keywords: | WIFI key prop | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
if you enter the wrong key and fail connecting to a wifi network, you have to reboot and start over
This is a break-apart of the issues listed in #7660.
Attachments (1)
Change History (8)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Blocking: | 7660 removed |
---|
comment:3 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 7 years ago
I tested this and didn't have a reboot issue and entered various characters for a password. I know there was some recent updates for wpa_supplement 2.6. May be worth a look. See #12281. I had an kernel panic issue with iprowifi3945 driver stability. Says "no rate table for channel; freq %u flags 0x%x" (0x8232aae0). (ieee80211_get_ratetable + 0xf9)
Have this driver issue while testing on hrev51880 x86 with iprowifi3945 driver (see: P_20180413_175911[1].jpg). Happens during initial bootup after splash screen completion. Didn't reboot computer (just exit debugger and will continue loading desktop fine)).
I'd say this is a driver issue and not wpa_supplement at this point.
See #12280 for syslog info attachment.
Device tested:
device Network controller [2|80|0] vendor 8086: Intel Corporation device 4222: PRO/Wireless 3945ABG [Golan] Network Connection
by , 7 years ago
syslog of iprowifi3945 driver/wpa_supplement 2.4 using hrev_51880
comment:6 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Probably fixed with new wpa_supplicant; at least it works here. Closing as fixed.
comment:7 by , 5 years ago
Milestone: | R1 → R1/beta2 |
---|
Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone
Are you able to reproduce this issue? The implemented workflow is as follows:
1) Try finding a stored key for the selected network and try to connect using it 2) If the connection fails (timeout with no success notification) or there were no stored credentials, bring up the dialog 3) Try to connect using the supplied credentials 4) When a connection is established successfully, store the credentials, otherwise go back to 2
The wpa_supplicant is told to shut down the association attempt when the timeout occurs, which probably is the root cause of this issue. It is probably related to disabling/reenabling the interface in the FreeBSD compatibility layer and might therefore also be driver specific. What setup did you test on?