Use a specific device ?

[Aleksander Morgado]

On Thu, May 28, 2015 at 4:41 PM, Jean-Christian de Rivaz <jc at eclis.ch> wrote:
>>>> Like I said on the NM lists, I'd rather have ModemManager read the
>>>> symlinks and advertise *those* over D-Bus instead of adding new
>>>> MM-specific tagging stuff to ModemManager itself.  Seems like a more
>>>> generic solution to me than "magic" tags.  It also ensures that you
>>>> cannot use the same tag for multiple devices.
>>>>
>>> Just for curiosity, how did you plan to find the symbolic link that point
>>> to
>>> the real ttyACMx ?
>>
>> That's an interesting question; as udev won't notify via events about
>> the links it creates (right?). We could list all files within /dev and
>> then use realpath() to see if any link file points to the real tty
>> device path, but that is too much I think. Tagging the specific device
>> in udev with a new "ID_MM_DEVICE_TAG" that is then exposed in DBus
>> could be much simpler to implement.
>>
>> But anyway, at the end, the setting of the udev rule (either tag or
>> link) depends directly on a developer or administrator setting it for
>> a specific use case. I wonder if that use case cannot be fulfilled
>> automatically in some other way. E.g. if you know you'll have to
>> support CDMA and GSM/UMTS modems, you could create 2 different
>> connection settings in NM that are not bound to any specific device,
>> and once the modem shows up in ModemManager decide in runtime which of
>> the settings should get applied to the modem to get it connected. CDMA
>> vs GSM/UMTS is an obvious thing, maybe you have to setup more runtime
>> checkes, but I don't think it should be impossible.
>>
>
> What's more complicated for a user like me is that the big picture includes
> two different projects: ModemManager and NetoworkManager. Whenever MM should
> provides more informations on D.Bus, or NM should have more runtime check,
> this mode of operation is actually poorly documented and I take a long time
> trying to understand before posting in the respective mailing list.
> Thankfully I got a working trick from the NM mailing list.
>

There's some documentation about what ModemManager is and the general
overview of how it works in the ModemManager manual here:
   http://www.freedesktop.org/software/ModemManager/api/latest/ref-overview.html

It doesn't really explain how it integrates within NetworkManager and
how NetworkManager uses ModemManager; mainly because NetworkManager is
not the only way to use ModemManager (although it really is the main
one). Anyway, yes, documentation could be improved a lot... patches
accepted! :)

> My proposition got that way:
> 1) By default ModemManager identify the modem on D-Bus using the device name
> (e.g. ttyACMx).
> 2) If ID_MM_DEVICE_TAG is provided from udev rules, then ModemManager use
> ID_MM_DEVICE_TAG value to identify the modem on D-Bus instead of 1).
> 3) If (choose a method here) then ModemManager use the modem ID / SIM ID to
> identify the modem on D-Bus instead of 1) and 2).

I still think that the ideal thing would be to have NetworkManager
settings tied to specific devices; but not identified by a
user-provided tag or a specific /dev/ttyX name. From my point of view,
NetworkManager should allow to either:
 a) Have connection settings not tied to any modem (possible nowadays).
 b) Have connection settings tied to a very specific modem (e.g. to a
specific IMEI, MEID...) or even better, SIM card (e.g. IMSI, SIM
ICCID...).

The fact that ModemManager exports the primary port in DBus is really
just a convenience for NetworkManager to provide a descriptive modem
interface device name in the logs (isn't it?). The device names are of
course not ensured to be the same across reboots, and therefore
identifying a modem via the exposed device name is never a good idea.
Hence, the suggestion to identify it directly by IMEI, MEID,... or via
the "Equipment ID" property.

Don't take me wrong, the idea of exposing in DBus the value of a given
property is feasible. But then, why does ModemManager have to do that?
If you want to have specific udev tags tied to a given modem, you can
still do that, and as ModemManager already exposes the full list of
ports of a modem, you could traverse each looking for the specific
udev tag. Don't know, I just don't see the value on complicating the
logic this way :/

-- 
Aleksander
https://aleksander.es