Use a specific device ?

[Aleksander Morgado]

Hey hey Jean-Christian

>> 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...).
>
>
> a) Is a trick not visible from a normal user point of view and will not
> solve b) situation.
>

That is really not true; it really depends on how it is presented to
the user. E.g. in GNOME Shell when you plug in a modem, it willl show
the list of available GSM settings that you can choose to use, if you
have more than one. If there is only one, and there is only one modem,
then you can just select the one given.

>From my point of view, a) solves your issue, unless you have multiple
modems from multiple carriers, which would need some additional logic
to detect which settings can be applied to which modem.

> b) Will not solve my problem as exposed in my first post:
>
> I want to configure all the systems of a network with the same configuration
> file, but the device port name change dynamically on each system. As the
> IMSI or MEID or ICCID is unique for each modem or SIM card, it will require
> a specific configuration on each system, exactly the opposite of what I
> want.
>

Still, you also have to configure the specific udev tag/rule in each
system as well. If you have just a single modem model for all systems,
you could set a generic udev rule that applies to that specific modem.
But then, why not just use the a) approach from above? See my last
paragraph in the email.

>> 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.
>
>
> Without trick NetworkManager require a specific device name to add a new gsm
> type connection. I learned from the NM malling list that I can modify the
> connection after his creation to remove the device name, but this is a hack
> that a normal user like me will be unable to find in the documentation.
>

It really isn't a trick or hack, it's been there forever AFAIK. I
mean, I've used gsm/cdma settings not bound to any device since a very
long time ago, since I started to hack in ModemManager actually. I
usually just create one single set of settings and I use the same set
of settings with all the modems I have during testing.

>> 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.
>
>
> How you do that from NetworkManager or an other MM client ? I am not certain
> that this is simpler than the ID_MM_DEVICE_TAG proposition.
>

Oh, that would be very simple to do. You get a set of port names (e.g.
ttyUSB0, ttyUSB1), and then you just use libudev to look for tags in
those devices.

> The reality is that udev is specifically designed to identify a device and
> add environment variable to solve this kind of problem. Why should MM client
> like NM redo the same work ? All MM have to do is to pass the already good
> value from udev rule to D-Bus so that MM client can refer to it, exactly
> like if MM will use the IMEI, MEID, IMSI, ICCID, to let the MM client refer
> to them.
>

The thing here is that ModemManager tries to be fully automatic; the
udev tags we have are to identify port-types and things like that.
There's no 'manual' configuration of ModemManager needed anywhere,
there's no configuration file, or anything. What I want to avoid is
adding what to me looks like specific configuration for a specific
need.

> The question is open regarding if it's the MM or NM job to select the fileds
> it need to pick up the right modem, but at lest can we agree that
> ModemManager is in the best place to publish those fields on D-Bus ?
>

Sure thing, if you want to publish those fields somewhere in DBus, MM
has the best position to do so, as it has the exact list of ports. I'm
not arguing that, I'm arguing whether explicitly detecting and
exposing those symlinks in DBus has any benefit at all.

So, your issue is that you want to have a single set of settings for
all modems that you may connect to your custom systems. So, let's say
that you'll have 10 huawei modems, all same model, with an AT&T sim
card each, and each modem will be plugged in one of 10 boxes. And you
want to have 1 single set of NM settings for all modems in all
systems. Ok, so what you want to do is creating 1 set of settings
bound to a "virtual" device name (that you e.g. specified manually as
a link to a tty or as a udev tag, let's call it /dev/gsm). The
settings you create, bound to /dev/gsm, will include e.g. the AT&T
APN. Well, instead of that, you can create 1 single set of settings
not bound to a specific device, with the AT&T APN; and that's it. I
really find that much simpler, but of course not sure if I'm missing
some more context on your setup.

-- 
Aleksander
https://aleksander.es