Re: Configure a connection for a gsm with dynamic ttyACMx

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]