Supplicant Errors When Running w/ D-Bus

Grant Erickson marathon96
Mon Nov 22 21:05:45 PST 2010


On Nov 22, 2010, at 7:39 PM, Grant Erickson wrote:
> I have been attempting to get running connman-0.63 and wpa_supplicant-0.7.3 on my TI / Mistral AM37x evaluation board with TI WL1271 evaluation module interface that has a WEXT-compatible driver.
> 
> Unfortunately, I get a few errors from the supplicant. Among them are a series of 'IWEVGENIE overflow' messages from the wpa_supplicant:
> 
> 	...
> 	daemon.notice wpa_supplicant[28351]: IWEVGENIE overflow
> 	...
> 
> Are these typically indicative of a driver error or something in the supplicant?
> 
> I also get the following error following a scan:
> 
> 	...
> 	IWEVGENIE overflow
> 	IWEVGENIE overflow
> 	IWEVGENIE overflow
> 	Received 4078 bytes of scan results (7 BSSes)
> 	BSS: Start scan result update 1
> 	BSS: Add new id 0 BSSID 00:27:0d:05:bf:55 SSID ''
> 	dbus: Register BSS object '/fi/w1/wpa_supplicant1/Interfaces/1/BSSs/0'
> 	BSS: Add new id 1 BSSID 00:16:c8:01:00:90 SSID '__'
> 	dbus: Register BSS object '/fi/w1/wpa_supplicant1/Interfaces/1/BSSs/1'
> 	BSS: Add new id 2 BSSID 00:1b:2f:4f:23:ee SSID '__'
> 	dbus: Register BSS object '/fi/w1/wpa_supplicant1/Interfaces/1/BSSs/2'
> 	wpa_parse_wpa_ie_rsn: malformed ie or unknown version
> 	process 31429: arguments to dbus_message_new_error() were incorrect, assertion
> 	...
> 
> which eventually leads to an abort in the D-Bus library:
> 
> 	process 31429: arguments to dbus_message_new_error() were incorrect, assertion "reply_to != NULL" failed in file /source/dbus-1.3.1/dbus/dbus-message.c line 1333.
> 	This is normally a bug in some application using the D-Bus library.
> 	  /lib/libdbus-1.so.3(+0x45260) [0x4026c260]
> 	  /lib/libdbus-1.so.3(+0x4b370) [0x40272370]
> 	  /lib/libdbus-1.so.3(+0x38798) [0x4025f798]
> 	  /lib/libdbus-1.so.3(dbus_message_new_error+0x1b4) [0x4024e184]
> 	  /sbin/wpa_supplicant(wpas_dbus_getter_bss_rsn+0x98) [0x377b0]
> 	  /sbin/wpa_supplicant() [0x35230]
> 	  /sbin/wpa_supplicant() [0x3536c]
> 	  /sbin/wpa_supplicant() [0x3679c]
> 	  /sbin/wpa_supplicant() [0x36cf8]
> 	  /sbin/wpa_supplicant() [0x10068]
> 	  /sbin/wpa_supplicant() [0x112a8]
> 	  /sbin/wpa_supplicant() [0x43884]
> 	  /sbin/wpa_supplicant() [0x40af0]
> 	  /sbin/wpa_supplicant() [0x41f68]
> 	  /sbin/wpa_supplicant() [0x13a60]
> 	  /sbin/wpa_supplicant() [0x3d150]
> 	  /sbin/wpa_supplicant() [0x447cc]
> 	  /lib/libc.so.6(__libc_start_main+0x118) [0x402da4c4]
> 	Aborted

This error seems to be coming from:

	static unsigned int fill_dict_with_properties(
	        DBusMessageIter *dict_iter, const struct wpa_dbus_property_desc *props,
	        const char *interface, const void *user_data)
	{
	        DBusMessage *reply;
	        DBusMessageIter entry_iter, ret_iter;
	        unsigned int counter = 0;
	        const struct wpa_dbus_property_desc *dsc;
    
	        for (dsc = props; dsc && dsc->dbus_property; dsc++) {
	                if (!os_strncmp(dsc->dbus_interface, interface,
	                                WPAS_DBUS_INTERFACE_MAX) &&
	                    dsc->access != W && dsc->getter) {
	->                      reply = dsc->getter(NULL, user_data); 

with the obvious NULL as the first parameter being in error. The static function fill_dict_with_properties is only called from two places:

	* get_all_properties
	* wpa_dbus_get_object_properties

The former, already containing a DBusMessage pointer, makes it easy to pass that on through to fill_dict_with_properties were we to modify its interface. However, the latter does not. However, where it is called, new DBusMessage pointers are created and could be passed. So, I propose:

	void wpa_dbus_get_object_properties(struct wpas_dbus_priv *iface,
					    const char *path, const char *interface,
	+				    DBusMessage *msg,
					    DBusMessageIter *dict_iter)

Thoughts?

Best,

Grant



More information about the Hostap mailing list