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 :) Some discussion is available here: http://bugzilla.gnome.org/show_bug.cgi?id=525305 In particular, bInterfaceProtocol seems to be always 1 in actual devices, so it cannot be relied upon for determining advanced command sets such as GSM/CDMA.
If we know that the device is a modem, I'm not sure that there's any obvious problem with making a callout to probe which command sets it supports?
Yes, but it should be done by applications (i.e. gnokii or NetworkManager), not by hal.
Why? This is exactly the sort of information that should live in HAL.
Read here: http://bugzilla.gnome.org/show_bug.cgi?id=525305#c1
HAL runs as root, and can run the callback before anything else binds to the device.
I added Dan Williams to the CC, it was his objection, not mine :) Can you list the specific probes that hal should do?
From a quick scan of the GSM and CDMA specs, doing AT+CSCS=? should give a list of the character sets supported by the device (it's actually intended for SMS, but...). This will include CDMA if the device supports CDMA, and GSM if it includes GSM. In principle, anyway - I don't have any CDMA hardware here to check that they actually do so...
Well, what happens if the port is open by something already? If the device can't be opened for some reason? How are the failure modes handled? It just seems like there are too many transient failures that could affect whether the device gets tagged correctly or not. And if it fails, what retries the discovery again later, and when does that thing determine when to retry? It just seems like autoprobing would be pretty prone to races and other hard-to-debug failures. For example, you'd have to ensure that HAL would send out the NewCapability signals if and only if the helper had quit and released the lock on the serial port.
(In reply to comment #8) > Well, what happens if the port is open by something already? If the device > can't be opened for some reason? How are the failure modes handled? It just > seems like there are too many transient failures that could affect whether the > device gets tagged correctly or not. And if it fails, what retries the > discovery again later, and when does that thing determine when to retry? > What do you think the chances are that someone opens the device right after it gets added? This would only happen if someone uses an udev rule to do so and it that case it's a user/distro bug for installing software that is not compatible with each other. > It just seems like autoprobing would be pretty prone to races and other > hard-to-debug failures. For example, you'd have to ensure that HAL would send > out the NewCapability signals if and only if the helper had quit and released > the lock on the serial port. >
I think you want AT+GCAP, not AT+CSCS: Aircard 850: ----------------- AT+GCAP +GCAP: +CIS707-A, +MS, +ES, +DS, +FCLASS Random 56K modem: ----------------- AT+GCAP +GCAP: +FCLASS,+MS,+ES,+DS I also tried on my Nokia N80 at one point and it also returned correct GSM standards. At least in the NM case, NM won't touch the device until HAL says that it's there and has the right supported command sets, so I think the NM case is OK. If you want to take a stab at probing with AT+GCAP we can just see how it turns out?
Yeah, my Nokia N95 returns this: AT+GCAP +GCAP: +CGSM,+DS,+W OK AT+CSCS=? +CSCS: ("UCS2","GSM","PCCP437","PCDN","IRA","8859-1","HEX") OK So seems like a pretty good way to detect capabilities.
Created attachment 16091 [details] [review] add support for CDC ACM modems This is the proposed patch that marks CDC ACM devices as v.25 modems. Please review. The patch is by Daniel Qarras, originally submitted here: http://lists.freedesktop.org/archives/hal/2008-April/011412.html
Created attachment 16380 [details] [review] modem prober for HAL
Created attachment 16381 [details] [review] FDI rules to call modem prober
Vitja's patch introduces probe-modem.c, but that is missing proper licensing information.
*** Bug 17272 has been marked as a duplicate of this bug. ***
Ubuntu's nm-applet is patched with probe support: https://code.launchpad.net/~network-manager/network-manager-applet/ubuntu.0.7 here's the related Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/268095
sorry, I ment network-manager: https://code.launchpad.net/~network-manager/network-manager/ubuntu.0.7
Vitja, can you clarify the licensing on your prober code? Is it standard HAL licensing? Just to be safe...
Antti, did you get a confirmation from Vitja about the licensing of his code before submitting the patch to Ubuntu? Just wondering, because your Ubuntu patch does have the GPL disclaimer in probe-modem.c, but the original code from Vitja does not. You're not supposed to give a license to code that you didn't write :)
Created attachment 19356 [details] probe-modem-licensed.c (In reply to comment #20) > Antti, did you get a confirmation from Vitja about the licensing of his code > before submitting the patch to Ubuntu? Just wondering, because your Ubuntu > patch does have the GPL disclaimer in probe-modem.c, but the original code from > Vitja does not. You're not supposed to give a license to code that you didn't > write :) Really? ;-P I contacted Vitja privately when this thread didn't seem to get anywhere: ========================================================================= Subject: Re: probe-modem.c Sender: Vitja Makarov <vitja.makarov@gmail.com> Recipient: Antti Kaijanmäki <antti@kaijanmaki.net> Date: 31.07.2008 14:26 Attachment: probe-modem-licensed.c Hi! 2008/7/31 Antti Kaijanmäki <antti@kaijanmaki.net>: > Hi, > > could you please attach new version of the patch you sent for > freedesktop bug #15346[1]? I'm working on NetworkManager and I would > like to incorporate your code to my NM branch, but it's not possible, > because probe-modem.c doesn't have proper licensing information. > > with best regards, > Antti Kaijanmäki > > [1] http://bugs.freedesktop.org/show_bug.cgi?id=3D15346 > license will be as in nm project gpl2+ vitja.
*** Bug 17313 has been marked as a duplicate of this bug. ***
Vitja, to include the code in HAL, it'll need to be AFL/GPLv2+ licensed. Is that OK with you?
(In reply to comment #23) > Vitja, to include the code in HAL, it'll need to be AFL/GPLv2+ licensed. Is > that OK with you? > Sure. As Antti Kaijanmäki wrote, I send him licensed code, and it's GPLv2+
Any update on this? Would be cool to have this included before F10 is out - a lot of mobile phones would be instantly supported.
Bug 17313 was closed as a duplicate of this one - I was asked to minicom to the phone and post the AT+GCAP? output - the phone is wrongly shown in NetworkManager as a CDMA phone (and as a consequence I think the wrong phone number for dialling is shown) when it is GSM. Here's the output: +GCAP: +CGSM,+FCLASS
Fixed in NM via nm-modem-probe, with NM 0.7.1 and later.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.