Re: Configure a connection for a gsm with dynamic ttyACMx

[Jean-Christian de Rivaz <jc eclis ch>]

Le 26. 05. 15 18:21, Dan Williams a écrit :
> On Tue, 2015-05-26 at 16:09 +0200, Jean-Christian de Rivaz wrote:
> > Hi Dan,
> >
> > My application is a network of embedded systems where each system can
> > have an internal or an external SIM card. For this kind of use the
> > device ID or IMSI will not help as there will be different on each
> > system and I want a unique configuration file that work on all systems.
> Understood.  In this case your are correct that DeviceID and SimID won't
> help.  However, be aware that kernel bus enumeration means that specific
> devices are not guaranteed to be found in the same order, and thus a
> modem that has ttyACM0 one time may get ttyACM3 the next time.  Also if
> the modem crashes and disconnects, sometimes if an application holds the
> serial port open and doesn't close it on disconnect, that tty cannot be
> re-used when the modem reappears, and a new one will be chosen.
>
> So my point is that the only way to get guaranteed matching between a
> modem and a connection is via the device ID or SIM ID, because kernel
> enumeration is not guaranteed to be stable and your tty numbers
> therefore may not be stable.

The fact that the kernel dynamically assign the ttyACMx number can't be 
changed I agree, but udev rules precisely allow to match a specific 
device and to set a variable if the rule match. This is exactly how 
ModemManager already work with the ID_MM_DEVICE_IGNORE for example. This 
is a reliable way to identify the port of the modem.

The proposed idea is to have a udev rule that contain something like 
this ENV(ID_MM_DEVICE_TAG_NAME)="gsm" if the rule match,  then 
ModemManager can use the tag 'gsm' as a fixed reference instead of the 
dynamic ttyACMx. Of course ModemManager will continue to use the dynamic 
ttyACMx internally to communicate with the modem but will use the 'gsm' 
tag on the D-Bus so that NetworkManager get a fixed name too.

Now if you prefer to use the device ID or the SIM ID, ModemManager could 
be configured by a udev rule like ENV(ID_MM_DEVICE_TAG_TYPE)="device-id" 
or "sim-id" for example.

> > An other proposition could be to let's tag the devices from the udev
> > rules and allow both ModemManager and NetworkManager use the tag to
> > refer to the device. One advantage of this proposition is that it allow
> The best way to do this would be to use the udev rules to add symlinks
> as you've found.  However, since the symlinking is N symlinks to 1
> kernel device (ttyACMx) ModemManager cannot really use symlinks as the
> actual control/data port names.
>
> > to use this tag differently, for example ModemManager could be
> > configured to override the tag with the device ID and/or IMSI to fit
> > your proposed use case.
> >
> > While doing my experiment, I used udev rules that created specific
> > symbolic links for the modem regardless of this actual ttyACMx. If
> > ModemManager could have a way to be configured to use the specific
> > symbolic links, then NetworkManager would have see a fixed device name.
> > This is also an acceptable way for me to solve the problem.
> I think instead, ModemManager should still use the normal kernel port
> names.  But it could also read symlink names for the ports and make that
> available in the D-Bus interface so that NetworkManager or other
> programs could use them for matching.  What do you think Aleksander?

This is an alternative of the ENV(ID_MM_DEVICE_TAG_NAME) trick to get 
the tag name. The fact that the name on D-Bus should be allowed to be 
different from the dynamic tty is the main part that you also agree on 
if I understand you correctly.

Jean-Christian