How to handle multiple SSIDs with the same BSS

Witold Sowa witold.sowa
Wed Dec 30 19:17:19 PST 2009


Marcel Holtmann pisze:
> Hi Jouni,
> 
>>> so networks configured via a configuration file get also exported via
>>> D-Bus right now?
>> Yes.
> 
> okay, then we might need an extra way to tell them apart. Especially
> since via D-Bus could modify them later on. And it would be nice to know
> if these changes are stored back to the configuration file or not.
> 
>>> The D-Bus connection is shared on a per process basis and that is on
>>> purpose. Otherwise it gets pretty nasty on the bus itself.
>>>
>>> So best would be to have a common message handler function and then
>>> depending on the destination service, dispatch it.
>> OK. I started working on common dbus code that both the old and new
>> interface share. This compiles, but I have not yet run any tests on it.
>> Anyway, this looks quite straightforward, so I would hope to get this
>> into working condition in the near future.
> 
> I can try to break your new code if you like :)
> 
I broke it:) Crashes on startup when another instance is already running:

Starting program:
/home/wsowa/projekty/nm/hostap/wpa_supplicant/wpa_supplicant -udd
dbus: Register D-Bus object '/fi/w1/wpa_supplicant1'

dbus_bus_request_name[dbus]: Resource temporarily unavailable

Could not request DBus service name: already registered.

dbus: Unregister D-Bus object '/fi/w1/wpa_supplicant1'


Program received signal SIGABRT, Aborted.
0x00007ffff6690645 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff6690645 in raise () from /lib64/libc.so.6
#1  0x00007ffff6691c33 in abort () from /lib64/libc.so.6
#2  0x00007ffff66cc8e8 in ?? () from /lib64/libc.so.6
#3  0x00007ffff66d2108 in ?? () from /lib64/libc.so.6
#4  0x00007ffff66d3c66 in free () from /lib64/libc.so.6
#5  0x000000000045cb5e in free_dbus_object_desc (obj_dsc=0x6c6a90) at
dbus/dbus_new_helpers.c:964
#6  0x00007ffff719e23c in ?? () from /lib64/libdbus-1.so.3
#7  0x00007ffff718db30 in dbus_connection_unregister_object_path () from
/lib64/libdbus-1.so.3
#8  0x00000000004641ae in wpas_dbus_deinit (priv=0x6c59f0) at
dbus/dbus_common.c:403
#9  0x00000000004643d2 in wpas_dbus_init (global=0x6c5950) at
dbus/dbus_common.c:383
#10 0x000000000040b78d in wpas_notify_supplicant_initialized
(global=0x6c5950) at notify.c:31
#11 0x000000000046cbc1 in wpa_supplicant_init (params=0x7fffffffdb60) at
wpa_supplicant.c:2320
#12 0x00000000004722ca in main (argc=<value optimized out>, argv=<value
optimized out>) at main.c:251

wpas_dbus_ctrl_iface_init fails in wpas_dbus_init so wpas_dbus_deinit is
called and tries to deinit dbus iface which wasn't initialized correctyl.

Can we change dbus.c and dbus_handlers.c file names to dbus_old.c and
dbus_old_handlers.c?

Regards,
Witek.
>> I did find a memory leak that was triggered by the new D-Bus code in
>> when getting network properties. Anyway, I don't know whether this could
>> have been severe enough to eat gigabytes of memory.. Well, maybe if you
>> were running an infinite loop of Get/GetAll properties on the Network
>> interface.
> 
> I was doing a lot of GetAll calls on various interfaces. And actually
> never restarting wpa_supplicant. So over time this could have been
> accumulated into being noticeable. I am currently just looking for the
> behavior and correctness of the new D-Bus interface.
> 
> Regards
> 
> Marcel
> 
> 
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap




More information about the Hostap mailing list