GNOME Bugzilla – Bug 565177
Huawei E160G 3G USB modem cannot connect
Last modified: 2009-02-23 14:27:58 UTC
Please describe the problem: This modem is registered OK and properly configured. But when trying to connect, it disconnects immediately. The problem may be provider-dependent, since there are reports of success to be found on the web. My provider is Oister.dk, a Danish data-service-only provider using 3.dk's net. Steps to reproduce: 1. Connect the modem 2. Set up an account for Oister.dk (now in the Gnome provider list SVN) 3. Restart NetworkManager in debugging, no-daemon mode and try to connect Actual results: Debug log excerpt: NetworkManager: <info> Searching for a network... NetworkManager: <debug> [1228941447.791863] nm_serial_debug(): Sending: 'AT+CREG?' NetworkManager: <debug> [1228941447.802718] nm_serial_debug(): Got: '+CREG: 0,3 OK' NetworkManager: <WARN> automatic_registration_response(): Automatic registration failed: registration denied. Expected results: I extracted these AT commands from an USB trace from windows XP: [...] +CREG: 3 ("Registration denied") +CGREG: 2 ("Not registered, searching") +CREG: 3 ("Registration denied") +CGREG: 1 ("Registered, home network") [...] So it looks like the CGREG command should be used to check connection status in this case. Does this happen every time? Yes. I have tried it on Ubuntu 8.10 as well as the git trunk code on Fedora 10 Other information: FWIW, doing 'sed --in-place s/CREG/CGREG/g src/nm-gsm-device.c' and rebuilding makes NetworkManager work flawlessly with this modem/provider. I have previously reported this on the mailing list: http://mail.gnome.org/archives/networkmanager-list/2008-December/msg00177.html The attachment posted there contains additional information.
I can confirm this problem and its apparent solution. I have the same modem and the same provider. I have been using Gnome PPP without problems, but NetworkManager kept breaking. I have been debugging for a few days, made a similar USB trace (on XP) and suspected wrong AT commands in NetworkManager. Apparently, this has now been proved. I have edited nm-gsm-device.c as suggested by Jacob and recompiled. It works. (Unfortunately, it seems a bit unstable, but that may be since I used version 0.7~~svn20081018t105859-0ubuntuu2-nm4). Best regards, Anders Bo
I can confirm this problem using the same E160 USB 3G+ key with a different provider (Orange in France, with an "Internet Everywhere Pass" contract). This happens on laptop with an Ubuntu 8.10 installed using network-manager n0.7~~svn20081018t105859-0ubuntu1.8.10.1 from intrepid-upgrades. From the original Ubuntu package sources (package network-manager_0.7~~svn20081018t105859-0ubuntu1), I just did sed --in-place s/CREG/CGREG/g src/nm-gsm-device.c as advised by Jacob and after apt-src build and dpkg -i install *.deb, the connection works fine (except for the fact that a GPRS connection occurs instead of a 3G+ connection under Windows - at the same physical location, where 3G+ is available).
This is able to be fixed in ModemManager, support for which just got integrated to NetworkManager trunk. It's not possible to fix it in current NetworkManager builds.
Those of you with the Huawei E160G, please post the output of '/sbin/lsusb' for me. If the hack is simple enough in the code, maybe I'll include in in 0.7.1.
$ lsusb Bus 006 Device 004: ID 058f:6377 Alcor Micro Corp. Multimedia Card Reader Bus 006 Device 002: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E270 HSDPA/HSUPA Modem Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 003: ID 046d:c50c Logitech, Inc. Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub I should probably have mentioned above that it shows up as an E220/E270. Thank you for looking into this, having a work-around in 0.7.1 would be excellent.
Hmm; if it shows up as an E220, then we'll need to figure out if the USB IDs are actually different than the E220, since the E220 doesn't need this quirk...
I see some references saying that the E220 has the same USB IDs, unfortunately.
Yes, 10-modem.fdi lists the same IDs for the E220: <!-- Huawei --> <match key="@info.parent:usb.vendor_id" int="0x12d1"> [...] <!-- E220,E220bis --> <match key="@info.parent:usb.product_id" int_outof="0x1003;0x1004"> On Windows the software sends the command AT+CGMM to which the modem responds "E160G" - can that be used?
Does it work on Linux once it's been used in Windows once, possibly with a firmware upgrade? Reports on Red Hat bugzilla indicate that (https://bugzilla.redhat.com/show_bug.cgi?id=466177). Interesting at least, though a workaround checking AT+CGMM doesn't look too bad.
Using it on Windows changed nothing for me. I'll see if I can find a firmware upgrade.
There are no firmware upgrades from Huawei for this device. There are some forum posts from people who have gotten upgrades from their provider, but I have seen no mention of versions newer than the one I have (which is 11.604.21.00.156).
It appears that 0.7.1 rc1 (as in Ubuntu jaunty daily build from yesterday) has the workaround implemented - thanks! One thing: After disconnecting and replugging the device, it was not possible to connect again. In Ubuntu 8.10 with my hacked NM 0.7.0, this issue is not present. I will investigate some more if it is still present in NM 0.7.1 rc2.