On Thu, 2011-05-05 at 16:54 +0200, Aleksander Morgado wrote: > 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.
I like it. I now see what you were talking about :) Let's push it to git master for now and we can cherry-pick to MM_05 later if it turns out it works well for all the devices we can find. I'm a bit wary of making such a big change in MM_05 right now given that I'd like to keep that branch pretty quiet in preparation for the 05 release. Dan _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
