The HTC Prophet (also rebadged in various ways - I've plugged in an Orange M600 SPV), is picked up by this snippet in /usr/share/hal/fdi/information/10freedesktop/10-modem.fdi (Fedora 9): <!-- HTC Apache SPV C500 Smart Phone (Verizon XV6700) --> <match key="@info.parent:usb.vendor_id" int="0x0bb4"> <match key="@info.parent:usb.product_id" int="0x00cf"> <match key="@info.parent:usb.interface.number" int="0"> <append key="info.capabilities" type="strlist">modem</append> <append key="modem.command_sets" type="strlist">IS-707-A</append> </match> </match> </match> In NetworkManager, it then appears as a CDMA device, and we are given a default number to dial of (IIRC) 77*. This doesn't work. It is a GSM device and needs to dial *99#. In NetworkManager changing the number to dial to this makes it work - it still describes it as CDMA but that's just cosmetic. lsusb is also identifying the model wrongly: [root@hodge run]# lsusb | grep SPV Bus 005 Device 029: ID 0bb4:00cf High Tech Computer Corp. SPV C500 Smart Phone Maybe a difference between Europe and the US?
Can you please discuss it with the NetworkManager guys? They should know how to deal with it.
When I've raised this kind of issue with the NetworkManager guys before they've told me that hardware detection is all the responsbility of hal-info and that I should file the bug here...
I hope Dan can take a look at this. This is from the commit log: > Please apply this patch to 10-modem.fdi to enable the use of the HTC > Apache (Verizon XV6700) Smart Phone as a CDMA modem. You must first > start the "WModem.exe" application on the phone to enable the device > to appear as a modem to the USB host. This will allow NetworkManager > 0.7.0 to automatically detect the phone as a modem when plugged in.
Any chance you could connect with minicom and do: AT+GCAP? and post the output here? I think in the end we do need to use probing to find out what standards the thing supports rather than relying on FDI files. There's been some movement on the issue in the past but that was blocked on stupid cards that needed PINs. I think we should just go ahead with probing and just don't do anything if the card needs a PIN before AT+GCAP. I'll look more into that in the near future.
*** This bug has been marked as a duplicate of bug 15346 ***
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.