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 _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
