Watching for available SIMs on D-Bus

Ladislav Michl ladis at linux-mips.org
Sun Jul 21 20:20:47 UTC 2019


On Sun, Jul 21, 2019 at 10:08:40PM +0200, Aleksander Morgado wrote:
> Hey,
> 
> > > > I need to collect informations about modems (for IMEI) and SIM cards
> > > > (for IMSI) available to system over D-Bus.
> > > >
> > > > While listening to signal InterfacesAdded on interface
> > > > org.freedesktop.DBus.ObjectManager does work as mentioned in
> > > > documentation, ie. returning properties on newly discovered modem,
> > > > I cannot get this work for SIm cards. Here listening to
> > > > PropertiesChanged for both Modem or SIM interface does not
> > > > return anything. Current "solution" is to look at SIM object
> > > > path after while, which gets SIM a chance to be discovered,
> > > > but I would prefer to know how to implement it "the right
> > > > way" (tm).
> > > >
> > >
> > > The "manager" object in ModemManager implements
> > > org.freedesktop.DBus.ObjectManager but ONLY for modem objects. This
> > > means that the ObjectManager interface only notifies about
> > > added/removed interfaces in modem objects.
> > >
> > > Once you have the path for an existing modem object with a
> > > "org.freedesktop.ModemManager1.Modem" interface, you should then
> > > monitor the "Sim" property in that interface, which will give you the
> > > DBus path to the SIM object available in the modem.
> >
> > Well, perhaps I didn't make above clear. I'm waiting for Modem object
> > to appear on the bus, which works reliably. Once it appears I'm hooking
> > "PropertiesChanged" on it which also works as you indicated above.
> > Here "Sim" property is also available and object it points to does not
> > emit changes [*]. So once new modem appears on the bus, its Sim
> > property contains valid path to Sim object, but Imsi property of that
> > object is empty at that time. However, asking again after some time gives
> > expected result.
> 
> I'm not sure why you're seeing this. The SIM object creation involves
> loading IMSI/ICCID as part of the creation, and only once all have
> been loaded (or failed to load) then we export the SIM object in DBus,
> with the properties already set. There is no "reloading" after the SIM
> object has already been exposed in DBus. I have never seen this issue
> when using libmm-glib, truth be told, I think you'll have to debug it
> further I'm afraid, or otherwise share a simple tester program that
> reproduces the issue.

I do not follow. You need to create SIM object to have something to issue
SendPin method on right? So after Sim is unlocked (I guess NetworkManager
sends it as it lives in NetworkManager's config file), IMSI is read and
property updated. Or does it work any other way around?

> > > It is "guaranteed" by the implementation that the SIM path does NOT
> > > change in the same modem object, though. If for any reason the SIM is
> > > ejected and changed, the actual modem object will be completely
> > > re-created and the modem object path will also change.
> >
> > A side question: Once ModemManager is restarted all the hooks to
> > "PropertiesChanged" has to be destroyed using "NameOwnerChanged"
> > onInterface "org.freedesktop.DBus" and then created again using
> > "InterfacesAdded" of "org.freedesktop.DBus.ObjectManager" to get
> > internal application state into sync with ModemManger. Is that
> > correct or does some more elegant shortcut exist?
> >
> 
> Once ModemManager is restarted, all the objects exposed by the old and
> the new MM processes are completely different, and MM itself has a
> different bus address. So, whenever MM goes away, you need to cleanup
> all the stuff that you were monitoring. The main issue you're having
> here is that you're doing all this low-level stuff yourself, I assume
> because you cannot use libmm-glib or ModemManagerQt, right?

I'm using sdbus-c++ the best D-Bus library I've ever seen :)

> > [*] debug on "PropertiesChanged" of "Modem" gives:
> > Property UnlockRequired at org.freedesktop.ModemManager1.Modem changed
> > Property State at org.freedesktop.ModemManager1.Modem changed
> > Property State at org.freedesktop.ModemManager1.Modem changed
> > Property State at org.freedesktop.ModemManager1.Modem.Modem3gpp.Ussd changed
> > Property Enabled at org.freedesktop.ModemManager1.Modem.Location changed
> > Property State at org.freedesktop.ModemManager1.Modem changed
> > Property State at org.freedesktop.ModemManager1.Modem changed
> > Property RegistrationState at org.freedesktop.ModemManager1.Modem.Modem3gpp changed
> > Property OperatorCode at org.freedesktop.ModemManager1.Modem.Modem3gpp changed
> > Property OperatorName at org.freedesktop.ModemManager1.Modem.Modem3gpp changed
> > Property State at org.freedesktop.ModemManager1.Modem changed
> > Property RegistrationState at org.freedesktop.ModemManager1.Modem.Modem3gpp changed
> > Property Bearers at org.freedesktop.ModemManager1.Modem changed
> > Property State at org.freedesktop.ModemManager1.Modem changed
> > Property SignalQuality at org.freedesktop.ModemManager1.Modem changed
> > Property State at org.freedesktop.ModemManager1.Modem changed
> >
> > As you can see there is no change on org.freedesktop.ModemManager1.Sim
> > which is probably okay, per what you wrote before, but that leaves me
> > with no nice solution. Suggestions?
> >
> 
> Wait, you won't see a property update on the
> "org.freedesktop.ModemManager1.Sim" interface by monitoring the
> PropertiesUpdated of the modem object. How about you monitor
> PropertiesUpdated on the SIM object instead?

Sorry, that handler is hooked to both "org.freedesktop.ModemManager1.Sim"
and "org.freedesktop.ModemManager1.Modem", but only changes from "Modem"
object are seen.

Thank you,
	ladis


More information about the ModemManager-devel mailing list