ModemManager: Letting plugins manage RS232 modems

[Aleksander Morgado <aleksander lanedo com>]

Hi all,

(sorry for the long email)

ModemManager plugins need several steps to know whether they can handle
a given connected modem. The flow is usually something like this:

        (1) Check vendor ID (and sometimes also product ID), with one of
        the following methods:
                (1.a) Use vendor/product IDs reported by udev (obtained
                from the USB interface)
                (1.b) Check for a specific envvar set in the udev device
                (e.g. ID_MM_ERICSSON_MBM). The vendor/product
                relationship w.r.t the envvar is moved to the udev rules
                file.

        (2) Check interface subsystem type (some plugins only support
        "tty"s, for example)

        (3) Check modem capabilities, to see if they are GSM or CDMA.
                (3.1) If capabilities already cached, just check them.
                (3.2) If capabilities not already cached, launch port
                probing:
                        (3.2.1) Probe capabilities. If any of the
                        following commands succeeds and we parse a valid
                        reply, the remaining ones are skipped.
                                (3.2.1.1) AT+GCAP (3 times). If all 3
                                get timed out, check if port is QCDM.
                                (3.2.1.2) ATI
                                (3.2.1.3) AT+CPIN?
                                (3.2.1.4) AT+CGMM
                        (3.2.2) Notify the probe end and let the plugin
                        check the capabilities in the signal handler.

All plugins, except for the generic one, will do the vendor ID check to
see if they can support the connected modem. Unfortunately, both (1.a)
and (1.b) methods to check vendor ID depend on the values reported by
udev, and sometimes they do not correspond with the real modem
vendor/product IDs:
 * For modems connected via an adapter (bluetooth, RS232<->USB, ...),
usually the adapter's vendor/product ID are reported by udev.
 * For modems connected to a RS232 port, there's no vendor/product ID
reported by udev.
 * Probably some other situations I can't think of...

So how can we let plugins know if they can handle these devices?

We could extend the port probing so that in addition to the
capabilities, we also try to query vendor and model via AT commands.
This would be done as a new step just after probing capabilities (3.2.1)
and before notifying the probe end (3.2.2):
 
        (3.2.1) Probe capabilities (...)
        (3.2.2) Probe vendor ID. If any of the following commands
        succeeds  and we parse a valid reply, the remaining ones are
        skipped. If all the commands fail, product probing is also
        skipped.
                (3.2.2.1) AT+CGMI
                (3.2.2.2) AT+GMI
                (3.2.2.3) ATI
        (3.2.3) Probe product ID. If any of the following commands
        succeeds and we parse a valid reply, the remaining ones are
        skipped.
                (3.2.3.1) AT+CGMM
                (3.2.3.2) AT+GMM
                (3.2.3.3) ATI
        (3.2.4) Notify the probe end and let the plugin check the
        capabilities/vendor/product in the signal handler.

This would allow plugins that expect (for example) RS232 modems, to do
an additional check on the vendor ID (and/or product ID) string reported
by the modem itself. These additional AT commands during probing would
be sent only if we got a successful capabilities query (so not tried if
the port is a QCDM one for example); and the replies could be cached in
the AT port handler, so at the end it shouldn't affect much the time
needed to setup the modem (as these commands are usually afterwards
issued when querying card info). This solution should be enough for both
RS232 modems connected directly to a RS232 port and for modems connected
to the PC via an adapter.

An implementation of this can be checked at the following commit:
https://gitorious.org/lanedo/modemmanager/commit/b06faebb748a18c5428afc8aa7a71b95d79a5fbe

And an example of how it can be used here:
https://gitorious.org/lanedo/modemmanager/commit/62ba095c26528eaa519598124b3494829bedf501

Some other ideas I thought about:
 (a) During whitelisting the RS232 port in udev, include an envvar like
ID_MM_MY_PLUGIN, so that the plugin can the look for it and if found,
assume it can handle the modem. But this doesn't work for RS232 modems
connected via a USB adapter; and also it would be very plugin-specific.
 (b) Add a custom init command in the specific plugin during port
probing, which checks vendor ID and compare it there. I don't dislike
this solution that much, but it ends up being very plugin-specific, not
a general solution.

Comments?

-- 
Aleksander