Use a specific device ?

[Dan Williams]

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:
> >>>> Like I said on the NM lists, I'd rather have ModemManager read the
> >>>> symlinks and advertise *those* over D-Bus instead of adding new
> >>>> MM-specific tagging stuff to ModemManager itself.  Seems like a more
> >>>> generic solution to me than "magic" tags.  It also ensures that you
> >>>> cannot use the same tag for multiple devices.
> >>>>
> >>> Just for curiosity, how did you plan to find the symbolic link that point
> >>> to
> >>> the real ttyACMx ?
> >>
> >> That's an interesting question; as udev won't notify via events about
> >> the links it creates (right?). We could list all files within /dev and
> >> then use realpath() to see if any link file points to the real tty
> >> device path, but that is too much I think. Tagging the specific device
> >> in udev with a new "ID_MM_DEVICE_TAG" that is then exposed in DBus
> >> could be much simpler to implement.
> >>
> >> But anyway, at the end, the setting of the udev rule (either tag or
> >> link) depends directly on a developer or administrator setting it for
> >> a specific use case. I wonder if that use case cannot be fulfilled
> >> automatically in some other way. E.g. if you know you'll have to
> >> support CDMA and GSM/UMTS modems, you could create 2 different
> >> connection settings in NM that are not bound to any specific device,
> >> and once the modem shows up in ModemManager decide in runtime which of
> >> the settings should get applied to the modem to get it connected. CDMA
> >> vs GSM/UMTS is an obvious thing, maybe you have to setup more runtime
> >> checkes, but I don't think it should be impossible.
> >>
> >
> > What's more complicated for a user like me is that the big picture includes
> > two different projects: ModemManager and NetoworkManager. Whenever MM should
> > provides more informations on D.Bus, or NM should have more runtime check,
> > this mode of operation is actually poorly documented and I take a long time
> > trying to understand before posting in the respective mailing list.
> > Thankfully I got a working trick from the NM mailing list.
> >
> 
> There's some documentation about what ModemManager is and the general
> overview of how it works in the ModemManager manual here:
>    http://www.freedesktop.org/software/ModemManager/api/latest/ref-overview.html
> 
> It doesn't really explain how it integrates within NetworkManager and
> how NetworkManager uses ModemManager; mainly because NetworkManager is
> not the only way to use ModemManager (although it really is the main
> one). Anyway, yes, documentation could be improved a lot... patches
> accepted! :)
> 
> > 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
...

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.

Dan