How to handle multiple SSIDs with the same BSS

[Marcel Holtmann]

Hi Jouni,

> > 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.

Regards

Marcel