Re: Configure a connection for a gsm with dynamic ttyACMx

[Dan Williams <dcbw redhat com>]

On Tue, 2015-05-26 at 16:09 +0200, Jean-Christian de Rivaz wrote:
> Le 26. 05. 15 15:28, Dan Williams a écrit :
> > On Tue, 2015-05-26 at 08:34 +0200, Thomas Haller wrote:
> > > Just leave "connection.interface-name" unspecified, for example via:
> > >
> > >     $ nmcli connection modify NAME connection.interface-name ""
> > It's important to note that this is the ModemManager *control port*,
> > which can be a TTY, a cdc-wdm, etc.
> >
> > One thing we want to do, but haven't done yet, is to add a way to lock
> > the connection to the device ID and/or the SIM ID (IMSI), which should
> > often be more useful than the control port itself.
>
> 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.

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

(note that we cannot change the kernel name (eg ttyUSB0 or ACM1) because
udev/kernel do not allow doing that; they only allow creating symlinks
to the kernel device.  Yes, you can 'mv ttyACM0 modem0' but that breaks
udev's 'by-id' symlinks so it's not a great option)

Dan