How to handle multiple SSIDs with the same BSS
Tue Dec 29 14:37:33 PST 2009
> > I never tried running the D-Bus interface together with a pre-configured
> > list of networks. Are we still supporting this. Is this a behavior we do
> > wanna support?
> Most of the time, I'm using a configuration file with networks and don't
> see any particular reason to not allow D-Bus API to be enabled at the
> same time.
so networks configured via a configuration file get also exported via
D-Bus right now?
> > And I got another crash. It seems to be race condition on startup when
> > two clients (one old interface, the other the new one) access the daemon
> > and try to bootstrap it.
> This is interesting one.. I was not aware how the D-Bus integration was
> done, but it looks like both the old and the new interface are sharing
> the same connection (dbus_bus_get() return value) and either code can
> dispatch new messages to be handled. However, the context pointer
> (user_data argument for message_handler callback) is completely
> different. This sounds like asking for problems..
> > #4 0x000000000042e00d in message_handler (connection=<value optimized out>,
> > message=<value optimized out>, user_data=<value optimized out>)
> > at dbus/dbus_new_helpers.c:1211
> This is in the new D-Bus code..
> > #5 0x0000003924c1cbee in _dbus_object_tree_dispatch_and_unlock (tree=0x216d860,
> > message=0x216e070) at dbus-object-tree.c:856
> > #6 0x0000003924c10a1c in dbus_connection_dispatch (connection=0x216dba0)
> > at dbus-connection.c:4485
> > #7 0x00000000004292f8 in process_watch (iface=0x216df50, watch=0x216d660,
> > type=EVENT_TYPE_READ) at dbus/dbus.c:60
> .. but it was dispatched through the old one.. With different user_data
> value, I would assume.
> I'm not familiar enough with libdbus to figure out what would be the
> best way of avoiding this. Would it be enough to just make both new and
> old code use the same context pointer (say, wpa_s)? Or would we need to
> add a common message_handler() function that libdbus would be called and
> we would then select proper context information based on whether this is
> for the new or old D-Bus API? Or should we try to somehow force separate
> D-Bus connections (if that can even be done) for both implementations?
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.
More information about the Hostap