#14349 closed bug (fixed)
wpa_supplicant segfault with atheroswifi driver
Reported by: | v.vill | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Network & Internet | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Greetings, I'm trying to use the updated FreeBSD11 stack to work with an Atheros wifi card, which has proven to be challenging (see #14249 and #14282).
When connecting to a WPA-encrypted network, wpa_supplicant crashes (see attached); and afterwards no wifi networks are detected, no matter how many processes I kill and respawn. I have to reboot the system to regain proper wifi network scanning. (Interestingly, I seem to be able to get a slow but nearly-stable wifi connection on unencrypted networks.)
I'm running hrev 52205 x86_64 with an AR9565 wifi chip.
Attachments (5)
Change History (20)
by , 6 years ago
Attachment: | wpa_supplicant-1153-debug-11-08-2018-18-05-18.report added |
---|
comment:1 by , 6 years ago
comment:2 by , 6 years ago
by , 6 years ago
Attachment: | net_server-982-debug-13-08-2018-20-12-22.report added |
---|
comment:3 by , 6 years ago
I’m not entirely sure the bug is triggered by wpa_supplicant; even without using encrypted networks, net_server tends to crash as well (see attached).
comment:4 by , 6 years ago
Also, when trying to regain wifi access by clicking on "Disable" then "Enable" in the Network preferences window, I managed to trigger a vm_page_fault KDL that looks a _lot_ like #14282. I’m not sure whether these are two separate problems, but in any case I’m also attaching it here.
comment:5 by , 6 years ago
Nah, that KDL is completely unrelated to #14282. Please open a new ticket for it.
comment:8 by , 6 years ago
Clean installs will still have wpa supplicant 2.4 until yesterday evening. After that hrev, they shod have 2.7. Can you see if it's then fixed?
comment:9 by , 6 years ago
I didn’t have a chance to reproduce the segfault, since it KDL’d before I got to that part :-/
See #14411.
comment:10 by , 6 years ago
OK, now that #14355 appears to be fixed I could reproduce the segfault again. See attached report & coredump.
by , 6 years ago
Attachment: | wpa_supplicant-1118-debug-28-08-2018-21-41-51.report added |
---|
Updated report
comment:11 by , 6 years ago
Huh. Since upgrading to hrev52300 the segfault has no longer been happening. It’s strange, because I can’t see any commit between hrev52297 and 52300 that could explain it.
Another possible factor for this issue, is that when connecting to a known encrypted network, wpa_supplicant has to request permission for accessing the keyring; when the segfault occurred, it always happened _before_ it asked for permission. So, perhaps some behavior changed there (or perhaps it was just a byproduct of #14355, but it did keep crashing for a while even after it was fixed).
tl;dr: seems to be fixed now, at least AFAICS.
comment:12 by , 6 years ago
Oops, turns out it's not completely gone; I did encounter the segfault again (roughly 1 out of 3 boot ups, with no discernable specific trigger). I'm attaching a new log (very similar though) in case it may help.
by , 6 years ago
Attachment: | wpa_supplicant-1136-debug-31-08-2018-21-07-41.report added |
---|
Updated report
comment:13 by , 6 years ago
I managed to somehow trigger this on my machine, though I'm still not sure what the circumstances of it were; after a reboot everything was normal again. I'll try to get it to happen again.
comment:14 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Wait. So is #14282 fixed then?