Use a specific device ?

[Jean-Christian de Rivaz]

Hey Aleksander,

Le 28. 05. 15 22:08, Aleksander Morgado a écrit :
> 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.

I can talk from my user experience trying to configure a embedded system 
without graphical capabilities. I have spend a full day around mmcli and 
nmcli without noticed the hack, and finally post in the malling list in 
the last hope.

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

A agree, this solve my particular problem right now because I have a 
single 2G/3G modem on that system. But I can forecast that one day 
someone will plug in it a external 4G USB modem in addition to the fixed 
internal 2G/3G USB modem and then the a) hack will not be enough.

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

Because someday the system could have more than one modem. And no I 
really don't want to configure udev rules specifically for each system: 
the modem would be the only reason why we have to not use the exact same 
filesystem image on all systems. Not an option.

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

Maybe it's obvious for you. Try to take the view of a newbie about MM 
and NM that have only mmcli and nmcli to configure his embedded system. 
Even now I am still unable to find a single example of this on the internet.

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

Sorry, but for the user point of view this is not appealing. If there is 
a udev rule to name a device, then the user expect to see that name on 
the application that use the device and ModemManager is the first in the 
list. And if ModemManager use the tag name, NetworkManager don't even 
have to look at the udev API to get the right name.

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

I understand that. Now as for the facts ModemManager already use udev 
environment variable as a kind of configuration information. I like the 
fact that ModemManager is as much automatic as possible, but as a user I 
also expect that a particular modem have a fixed name regardless of his 
serial device name dynamic and auto probing.

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

Yes this work that way right now on the systems. My observation are:
1) It's really hard to find example of this mode of operation for 
mmcli/nmcli users.
2) The name of the modem will change in a unpredictable way, making 
newbie users confused.
3) This will not work anymore if someone upgrade the system with an 
additional external modem.

Jean-Christian