Watching for available SIMs on D-Bus
Aleksander Morgado
aleksander at aleksander.es
Sun Jul 21 20:48:19 UTC 2019
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?
>
Ohhh I know what the issue is :D your question helped.
The correct sequence is the following:
* The SIM object is created in MM's logic only after all
IMSI/ICCID/MCC/MNC are loaded (attempted to be loaded) from the modem.
* Once the SIM object is fully created, the object is exported in DBus.
* And once it has been exported in DBus, the "sim" property of the
"Modem" interface in the modem object is populated with the path of
the SIM object in DBus.
* And then, applications (e.g. NetworkManager) can call SendPin() or
any other method on the SIM object.
* After SIM-PIN unlocked, we launch a "reinitialization" of the SIM
object properties, so that any property that failed to load due to the
SIM-PIN lock can now be reloaded.
I believe that last point is what you're seeing.
For reference:https://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/mm-iface-modem.c#n4958
You definitely need to monitor PropertiesChanged in the SIM object, as
they may be updated during runtime, e.g. when loaded only after
SIM-PIN unlocked.
> > > > 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 :)
>
If you're using a low-level library you definitely need to handle all
those things yourself I'm afraid, yes. Or write a new client-side MM
library using sdbus-c++ :D
> > > [*] 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.
Please try hooking it to the SIM object. All objects exposed by MM
implement "org.freedesktop.DBus.Properties" (with "PropertiesChanged"
signal).
--
Aleksander
https://aleksander.es
More information about the ModemManager-devel
mailing list