Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#26817 - [wpa_supplicant] crash on scan

Attached to Project: Arch Linux
Opened by Tom Gundersen (tomegun) - Wednesday, 09 November 2011, 05:23 GMT
Last edited by Thomas Bächler (brain0) - Saturday, 13 October 2012, 20:51 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Running wpa_supplicant manually with debugging enabled gives this crash:

Scan requested (ret=0) - scan timeout 30 seconds
nl80211: Event message available
nl80211: Scan trigger
nl80211: Event message available
nl80211: New scan results available
Received scan results (9 BSSes)
nl80211: Scan results indicate BSS status with 00:60:64:23:f5:76 as associated
BSS: Start scan result update 4
BSS: Add new id 10 BSSID f4:ec:38:c8:d5:b0 SSID 'edwinahu'
dbus: Register BSS object '/fi/w1/wpa_supplicant1/Interfaces/1/BSSs/10'
wpa_parse_wpa_ie_wpa: ie count botch (pairwise), count 0 left 2
process 3553: arguments to dbus_message_new_error() were incorrect, assertion "reply_to != NULL" failed in file dbus-message.c line 1335.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace


This always happens on the same SSID (edwinahu). "iwlist wlan0 scan" tells this about the SSID:


Cell 06 - Address: F4:EC:38:C8:D5:B0
Channel:5
Frequency:2.432 GHz (Channel 5)
Quality=22/70 Signal level=-88 dBm
Encryption key:on
ESSID:"edwinahu"
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s
Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
Mode:Master
Extra:tsf=0000000928ccbd80
Extra: Last beacon: 6273ms ago
IE: Unknown: 0008656477696E616875
IE: Unknown: 010882848B960C121824
IE: Unknown: 030105
IE: Unknown: 050400010000
IE: Unknown: 2A0100
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : WEP-40
Pairwise Ciphers (0) :
Authentication Suites (0) :
IE: WPA Version 1
Group Cipher : WEP-40
Pairwise Ciphers (0) :
Authentication Suites (0) :
IE: Unknown: 32043048606C
IE: Unknown: DD180050F2020101880003A4000027A4000042435E0062322F00
IE: Unknown: DD1E00904C334E111BFF00000000000000000000000000000000000000000000
IE: Unknown: 2D1A4E111BFF00000000000000000000000000000000000000000000
IE: Unknown: DD1A00904C3405071B00000000000000000000000000000000000000
IE: Unknown: 3D1605071B00000000000000000000000000000000000000
IE: Unknown: DD0900037F01010000FF7F
IE: Unknown: DD0A00037F04010000004000


It seems to me that the problem is, firstly, that there is an error whilst parsing the IE stuff. The crash is however caused by an invalid use of the dbus_message_new_error() function used when reporting the parsing error.

I tried rebuilding dbus with --enable-aserts (which should pass -rdynamic to libtool), but I still could not get a backtrace.
This task depends upon

Closed by  Thomas Bächler (brain0)
Saturday, 13 October 2012, 20:51 GMT
Reason for closing:  Works for me
Additional comments about closing:  It is probably fixed, but nobody can reproduce it anymore.
Comment by Tom Gundersen (tomegun) - Wednesday, 09 November 2011, 05:24 GMT
I should add: enabling asserts decrease the frequency of the crashes a lot (now it is about once every 10 minutes).
Comment by Thomas Bächler (brain0) - Wednesday, 09 November 2011, 09:38 GMT Comment by Tom Gundersen (tomegun) - Wednesday, 09 November 2011, 09:57 GMT
Thanks for looking into this Thomas. I should have checked Fedora first. It seems that I can not reproduce at the moment (I guess the offending AP is switched off), but I'll test the patch that landed in F16 as soon as the AP reappears.

(This is the link to the patch the used (don't know if it exactly the same as in the bug report): <http://pkgs.fedoraproject.org/gitweb/?p=wpa_supplicant.git;a=blob_plain;f=0001-dbus-clean-up-new-D-Bus-interface-getters-setters.patch;h=e06b5db9e49690620f8ae2ff8c9b7fb22369bd1b;hb=HEAD>).
Comment by Tom Gundersen (tomegun) - Wednesday, 09 November 2011, 20:34 GMT
I have not seen the AP again, in case I don't, maybe it would be worth applying the patch anyway. I noticed that it is now upstream: http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commit;h=6aeeb6fa21bc072ba92ce9423ba5c0417e8c0bf5
Comment by Thomas Bächler (brain0) - Wednesday, 09 November 2011, 21:50 GMT
Good, last time I checked I didn't find it upstream.
Comment by Hargobind Khalsa (khalsah) - Saturday, 07 January 2012, 06:37 GMT
I've been having the same problem when I was at one particular location (bad enough that wireless was pretty much useless), rebuilding wpa_supplicant from ABS with the aforementioned patch (https://bugzilla.redhat.com/attachment.cgi?id=491018&action=diff) fixed the problem for me.

(Side note, #25465 appears to be a duplicate of this bug.)
Comment by Thomas Bächler (brain0) - Saturday, 07 January 2012, 16:27 GMT
Can someone please point to where this patch has been commited upstream? Thanks.
Comment by Thomas Bächler (brain0) - Saturday, 07 January 2012, 16:58 GMT
Oops, Tom provided a link, I completely overlooked that.

Loading...