GNOME Bugzilla – Bug 525305
Better way to detect GSM mobile phones
Last modified: 2008-04-04 08:01:50 UTC
Just noticed at http://blogs.gnome.org/dcbw/2008/03/02/networkmanager-your-gsm-mobile-and-you/ that the suggested way to detect GSM mobile phone is as follows: <match key="@info.parent:usb.vendor_id" int="0x0421"> <match key="@info.parent:usb.product_id" int="0x0445"> <match key="@info.parent:usb.interface.number" int="8"> e.g. by vendor and product id, and usb interface number. This is really inefficient as you'd have to create a separate entry for each mobile phone, and there are dozens or hundreds of models. Most modern mobiles use USB CDC ACM specification, and accordingly the modem interface is using a defined USB interface class and subclass: Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 8 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 8 CDC Comms Interface I'm not sure what is the exact .fdi syntax to use the class and subclass values, but you can probably work it out :) Further improvement: make use of the bInterfaceProtocol too. Other information:
This is a good suggestion; but it's more appropriate as a hal-info bug rather than a NetworkManager one. The one problem is that just checking the USB subclass/protocol won't tell you what command sets the device supports, which is what the HAL .fdi stuff was supposed to do in the first place. It's not enough to know that the device is just a modem (which is what subclass/protocol do) but we need to know whether the device supports GSM AT commands, CDMA AT commands, or both. That can be found out by sending commands to the device, but that's ugly and ultimately unworkable, since you want to know what the device is when you plug it in, irregardless of whether you can talk to the device first (something else might have the port, you might not have permissions to talk to the port yet, etc).
Oh, but bInterfaceProtocol is meant exactly for specifying supported command sets, no? Here are the possible protocol values for modem devices, from CDC spec: 01h ITU-T V.250 AT Commands: V.250 etc 02h PCCA-101 AT Commands defined by PCCA-101 03h PCCA-101 AT Commands defined by PCCA-101 & Annex O 04h GSM 7.07 AT Commands defined by GSM 07.07 05h 3GPP 27.07 AT Commands defined by 3GPP 27.007 06h C-S0017-0 AT Commands defined by TIA for CDMA
interesting; so for th eexample you give above, how come it doesn't show that it supports GSM bits then? Or is that not a phone you've connected?
Actually, that is a GSM phone, and a quick google search seems to indicate that bInterfaceProcol is always reported as 1 (basic AT set) with most if not all phones from various vendors, GSM or not. It's just useless then. So you'd need further heuristics (ugly), a big database of phones (logistics nightmare), or a manual selection of appropriate dial script (suboptimal user experience, but that's how in fact Apple does it in OS X :). On the other hand, if you only want to get online with a GSM phone, you simply need to dial the magic number of *99#. I don't know about CDMA though, but if they use the same number, then at least NM use case is covered. For things like phonebook, calendar, SMS messages and filesystem access modern phones are using OBEX interfaces anyway, so maybe we could leave it at that...
Should I refile this as a hal-info bug? If you just add the basic rule that class 2/subclass 2 devices are modems with a v.25 command set and close this bug, I'd be happy.
yeah, would be best to file it with hal-info. While that could add the 'modem' capability automatically for many devices, fdi files would still be required to add the correct CDMA/GSM command sets though...
Filed here http://bugs.freedesktop.org/show_bug.cgi?id=15346