Re: Configure a connection for a gsm with dynamic ttyACMx

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.


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