Re: Configure a connection for a gsm with dynamic ttyACMx

[Dan Williams <dcbw redhat com>]

On Tue, 2015-05-26 at 19:04 +0200, Jean-Christian de Rivaz wrote:
> 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.

Yes, I would prefer to do this without more tags, but using the normal
symlink scheme that udev already supports well.  This also makes it
non-ModemManager-specific since symlinks are often used for other
programs as well.

Dan