Use a specific device ?

[Dan Williams]

On Thu, 2015-05-28 at 22:26 +0200, Jean-Christian de Rivaz wrote:
> Le 28. 05. 15 21:54, Dan Williams a écrit :
> > On Thu, 2015-05-28 at 18:39 +0200, Aleksander Morgado wrote:
> >> On Thu, May 28, 2015 at 4:41 PM, Jean-Christian de Rivaz <jc at eclis.ch> wrote:
> >>
> >>> My proposition got that way:
> >>> 1) By default ModemManager identify the modem on D-Bus using the device name
> >>> (e.g. ttyACMx).
> >>> 2) If ID_MM_DEVICE_TAG is provided from udev rules, then ModemManager use
> >>> ID_MM_DEVICE_TAG value to identify the modem on D-Bus instead of 1).
> >>> 3) If (choose a method here) then ModemManager use the modem ID / SIM ID to
> >>> identify the modem on D-Bus instead of 1) and 2).
> >> I still think that the ideal thing would be to have NetworkManager
> >> settings tied to specific devices; but not identified by a
> >> user-provided tag or a specific /dev/ttyX name. From my point of view,
> >> NetworkManager should allow to either:
> >>   a) Have connection settings not tied to any modem (possible nowadays).
> >>   b) Have connection settings tied to a very specific modem (e.g. to a
> >> specific IMEI, MEID...) or even better, SIM card (e.g. IMSI, SIM
> >> ICCID...).
> >>
> >> The fact that ModemManager exports the primary port in DBus is really
> >> just a convenience for NetworkManager to provide a descriptive modem
> >> interface device name in the logs (isn't it?). The device names are of
> >> course not ensured to be the same across reboots, and therefore
> >> identifying a modem via the exposed device name is never a good idea.
> >> Hence, the suggestion to identify it directly by IMEI, MEID,... or via
> >> the "Equipment ID" property.
> >>
> >> Don't take me wrong, the idea of exposing in DBus the value of a given
> >> property is feasible. But then, why does ModemManager have to do that?
> >> If you want to have specific udev tags tied to a given modem, you can
> >> still do that, and as ModemManager already exposes the full list of
> >> ports of a modem, you could traverse each looking for the specific
> >> udev tag. Don't know, I just don't see the value on complicating the
> >> logic this way :/
> > How about just reading g_udev_device_get_device_file_symlinks () and
> > exposing that information as an "Aliases(as)" property on the MMModem
> > object?
> >
> > # cat /etc/udev/rules.d/90-huawei-symlink.rules
> > ACTION=="add", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1001", SUBSYSTEM=="tty", SYMLINK+="gsmmodem1_%n"
> >
> > # udevadm info --query=all /dev/ttyUSB2
> > ...
> > S: gsmmodem1_2
> > S: serial/by-id/usb-ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ_HUAWEI_Mobile-if02-port0
> > S: serial/by-path/pci-0000:00:14.0-usb-0:1:1.2-port0
> > ...
> 
> Good advance, thanks. Certainly a working idea for modem that expose a 
> single serial device, but how this will work with a modem that expose 
> multiple serial devices?
> 
> For example I have a modem that expose no less than 7 serial devices. I 
> can use the ENV{ID_USB_INTERFACE_NUM}=="xx" to select a specific serial 
> device of the modem and assign a fixed symbolic link to it like this:
> 
> ls -al /dev/gsm*
> lrwxrwxrwx 1 root root 7 May 28 22:05 /dev/gsm0 -> ttyACM1
> lrwxrwxrwx 1 root root 7 May 28 22:05 /dev/gsm1 -> ttyACM2
> lrwxrwxrwx 1 root root 7 May 28 22:05 /dev/gsm2 -> ttyACM3
> lrwxrwxrwx 1 root root 7 May 28 22:05 /dev/gsm3 -> ttyACM4
> lrwxrwxrwx 1 root root 7 May 28 22:05 /dev/gsm4 -> ttyACM5
> lrwxrwxrwx 1 root root 7 May 28 22:05 /dev/gsm5 -> ttyACM6
> lrwxrwxrwx 1 root root 7 May 28 22:05 /dev/gsm6 -> ttyACM7

Yes, many modems do this.  To handle it, if the modem actually cares
about which ports are control vs. auxiliary or GPS or whatever, we "tag"
them in ModemManager.  That is done by inspecting either (a) the Windows
driver .INF files or (b) reading modem documentation from the vendor to
determine what the modems preferred control port is.

We should strive to have the control port stable for all modems that
expose multiple control ports (be they AT, QMI, MBIM, etc), though note
that the control port can even change on firmware upgrades.  Once you
have that, you can easily write additional udev rules to test for that
tag and add your own symlink.

Which modem is this BTW?

> Guessing what symbolic link name will be selected by ModemManager is not 
> trivial . From experience this is sometime the first one, sometime the 
> 3th, I think this depend on some timings on the modem, or the USB bus, 
> or into the kernel. From a user point of view I don't see an advantage 
> over the real device name as it's still not a fixed one.

If we know exactly what port is the preferred control port, then we
should add static ModemManager tags for that modem like we do many other
devices.  That way ModemManager will always use the primary port, and
will report that port to NetworkManager as the "control" port.

NetworkManager only deals with the control port and the data port, so it
would only do device/symlink matching on the control port since data
ports come and go.  The other ports are irrelevant to NetworkManager
since they have nothing to do with network connections, they are an
implementation detail of how the modem works, which is hidden (by
design) by ModemManager.

> Obviously a single symbolic link can't point to multiple serial devices. 
> And an user don't have to study the modem technical details to select 
> himself one of the specific serial device as he expect that ModemManager 
> will automatically probe the serial devices and select the appropriate one.
> 
> I still think that the ID_MM_DEVICE_TAG give more advantage as the user 
> only have to give a single udev rule to tag all the serial devices of a 
> particular modem with the same tag and let ModemManager do his auto 
> probing. Whenever the serial device is selected by ModemManager is a 
> internal detail not in the direct interest of the user. What the user 
> want is just a fixed name to refer to the modem.
> 
> > I suppose we could also do this on the NM side instead of ModemManager,
> > but that would prevent other non-udev-based schemed in ModemManager in
> > the future.  I guess I'm fine with either way, either a new MM property
> > or having NM look this up.
> >
> 
> I you follow the previous paragraph, you will understand that it's 
> clearly the job of ModemManager. This just plain logic as this is the 
> only entity in the chain that receive the udev event about the modem.

I don't necessarily think it is ModemManager's job.  Since what you want
in the end is to tie a specific NM connection to a specific modem (based
on type, slot #, whatever), it's the job of NetworkManager to figure
that out for you.  ModemManager can certainly help if we can figure out
a clean generic way to do that.

Dan