Connection is successfully established to a WPA router, but after a while, wpa_supplicant crashes. The proximate cause of the crash is pretty obvious from the backtrace: Program received signal SIGABRT, Aborted. 0x00000037c8636285 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x00000037c8636285 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00000037c8637b9b in abort () at abort.c:92 #2 0x00000037d262f815 in _dbus_abort () at dbus-sysdeps.c:94 #3 0x00000037d26269b1 in _dbus_warn_check_failed ( format=0x37d2635810 "arguments to %s() were incorrect, assertion \"%s\" failed in file %s line %d.\nThis is normally a bug in some application using the D-Bus library.\n") at dbus-internals.c:289 #4 0x00000037d261b402 in dbus_message_new_error (reply_to=0x0, error_name=0x495370 "fi.w1.wpa_supplicant1.UnknownError", error_message=0x4952f0 "invalid WPA IE") at dbus-message.c:1334 #5 0x000000000045cd9d in wpas_dbus_getter_bss_wpa (message=0x0, bss=0x171a2c0) at dbus/dbus_new_handlers.c:2731 #6 0x0000000000456d77 in fill_dict_with_properties (dict_iter=0x7fffb35db2e0, props=<optimized out>, interface=0x49379d "fi.w1.wpa_supplicant1.BSS", user_data=0x171a2c0) at dbus/dbus_new_helpers.c:101 #7 0x0000000000457c9f in wpa_dbus_get_object_properties (iface=<optimized out>, path=0x7fffb35db360 "/fi/w1/wpa_supplicant1/Interfaces/1/BSSs/40", interface=0x49379d "fi.w1.wpa_supplicant1.BSS", dict_iter=0x7fffb35db2e0) at dbus/dbus_new_helpers.c:873 #8 0x0000000000457ed7 in wpas_dbus_signal_bss ( bss_obj_path=0x7fffb35db360 "/fi/w1/wpa_supplicant1/Interfaces/1/BSSs/40", sig_name=<optimized out>, properties=1, wpa_s=<optimized out>) at dbus/dbus_new.c:183 #9 0x0000000000459202 in wpas_dbus_signal_bss_added ( bss_obj_path=0x7fffb35db360 "/fi/w1/wpa_supplicant1/Interfaces/1/BSSs/40", wpa_s=0x171a850) at dbus/dbus_new.c:211 #10 wpas_dbus_register_bss (wpa_s=0x171a850, bssid=<optimized out>, id=40) at dbus/dbus_new.c:1271 #11 0x000000000040b680 in wpas_notify_bss_added (wpa_s=0x171a850, bssid=0x173a780 "", id=40) at notify.c:199 #12 0x000000000040c8aa in wpa_bss_add (res=0x1736fb0, ssid_len=13, ssid=0x1736ff2 "TransitMaster\001\004\202\204\v\026\003\001\v\005\004\001\n", wpa_s=0x171a850) at bss.c:138 #13 wpa_bss_update_scan_res (wpa_s=0x171a850, res=0x1736fb0) at bss.c:347 #14 0x0000000000469354 in wpa_supplicant_get_scan_results (wpa_s=0x171a850, info=0x0, new_scan=1) at scan.c:659 #15 0x0000000000465da0 in wpa_supplicant_event_scan_results (data=0x0, wpa_s=0x171a850) at events.c:888 #16 wpa_supplicant_event (ctx=0x171a850, event=<optimized out>, data=0x0) at events.c:1632 #17 0x000000000046c82d in wpa_driver_wext_event_wireless (len=<optimized out>, data=<optimized out>, drv=0x171a3c0) at ../src/drivers/driver_wext.c:509 #18 wpa_driver_wext_event_rtm_newlink (ctx=0x171a3c0, ifi=<optimized out>, buf=<optimized out>, len=<optimized out>) 19 0x0000000000475501 in netlink_receive_link (h=0x7fffb35db930, cb=<optimized out>, netlink=<optimized out>) at ../src/drivers/netlink.c:36 #20 netlink_receive_link (h=<optimized out>, cb=<optimized out>, netlink=<optimized out>) at ../src/drivers/netlink.c:204 #21 netlink_receive (sock=6, eloop_ctx=0x171a470, sock_ctx=<optimized out>) at ../src/drivers/netlink.c:71 #22 0x000000000040e793 in eloop_sock_table_dispatch (table=0x6b08c8, fds=0x171a680) at ../src/utils/eloop.c:216 #23 0x000000000040f0c6 in eloop_run () at ../src/utils/eloop.c:550 #24 0x0000000000464a09 in wpa_supplicant_run (global=0x1715eb0) at wpa_supplicant.c:2389 #25 0x00000000004083c0 in main (argc=<optimized out>, argv=<optimized out>) at main.c:274 fill_dict_with_properties() passes in a NULL message to the getter, so there is no 'reply' passed to dbus_message_new_error() and it asserts. But the question of why it would be saying "Invalid WPA IE" is more obscure to me.I traced into it, and the parsing path it takes is: #0 wpa_parse_wpa_ie_wpa (data=0x7fffb35db120, wpa_ie_len=20, wpa_ie=0x173a827 "\335\022") at ../src/rsn_supp/wpa_ie.c:76 76 if (wpa_ie_len < sizeof(struct wpa_ie_hdr)) { (gdb) p wpa_ie $9 = (const u8 *) 0x173a827 "\335\022" (gdb) p wpa_ie[0] $10 = 221 '\335' (gdb) p wpa_ie[0]@22 $12 = "\335\022\000P\362\001\001\000\000P\362\000\000\000\001\000\000\240\370\000\000" And I think it bailed at: 111 if (count == 0 || left < count * WPA_SELECTOR_LEN) { 112 wpa_printf(MSG_DEBUG, "%s: ie count botch (pairwise), " 113 "count %u left %u", __func__, count, left); 114 return -1; (gdb) But since the IE looks short hopefully that's possible to verify manually, since as always tracing through optimized code is a little dicey.
*** Bug 689115 has been marked as a duplicate of this bug. ***
Created attachment 491018 [details] Patch that fixes the D-Bus assertion OK, had a chance to be back in the same location with the same nearby AP that was feeding the offending data and got annoyed enough to come up with a patch. (Also, with NM 0.9, the crash seems to occur much more frequently and make using the network impossible.) Here's a patch that fixes the assertion failure and just skips the WPA property that can't be parsed - it's a little ugly - since there are *lots* of code paths in dbus_new_handlers.c that separately could potentially trigger this, I just #defined dbus_message_new_error to a version that doesn't throw the assertion but creates an error message message as best as possible from the result. It might also be desirable to log in the code that currently does: DBUS_MESSAGE_TYPE_ERROR) { dbus_message_unref(reply); continue; } in fill_dict_with_properties(), but on the other hand, that's going to result in a lot of log traffic if a parsing error is encountered so I just left it as is. (The downside of not logging, is that if you actually have problems parsing the data provided by the AP you *do* want to connect to, then that's going to be hard to debug.) I haven't investigated the problem with WPA IE parsing - but this (or a cleaner version) is separately right.
wpa_supplicant-0.7.3-8.fc15
Seems to have fixed it for me! Thanks so much. Push to updates? (I found this issue difficult to track down to this bug)
I had a similar issue. Tried out wpa_supplicant-0.7.3-8.fc15, and it fixes it for me to. Thanks!
I had the same WiFi issue at one location. Updating to wpa_supplicant-0.7.3-8 fixed it. For some reason its not in updates-testing?!
I've just upgraded to F15 and hit this problem and similarly tracked it down to trying to trying to report invalid WPA IE when the message pointer is NULL before finding this... Patched locally, but an official update would be nice.
wpa_supplicant-0.7.3-9.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/wpa_supplicant-0.7.3-9.fc15
wpa_supplicant-0.7.3-9.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/wpa_supplicant-0.7.3-9.fc16
Package wpa_supplicant-0.7.3-9.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing wpa_supplicant-0.7.3-9.fc15' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/wpa_supplicant-0.7.3-9.fc15 then log in and leave karma (feedback).
wpa_supplicant-0.7.3-9.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
wpa_supplicant-0.7.3-9.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.