This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 466177 - NetworkManager detects but doesn't work with huawei E160G USB 3G dongle
NetworkManager detects but doesn't work with huawei E160G USB 3G dongle
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F10Target
  Show dependency treegraph
 
Reported: 2008-10-08 17:29 EDT by Peter Robinson
Modified: 2009-05-12 13:00 EDT (History)
7 users (show)

See Also:
Fixed In Version: 0.7.0.99-1.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-08 15:33:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
huawei e160g messages output (16.68 KB, text/plain)
2008-10-08 17:31 EDT, Peter Robinson
no flags Details
NM with one device listed 3 times (142.18 KB, image/png)
2008-10-08 17:34 EDT, Peter Robinson
no flags Details
NM ddebug output (5.75 KB, text/plain)
2008-11-05 06:37 EST, Peter Robinson
no flags Details
Associated dmesg output (2.28 KB, text/plain)
2008-11-05 06:38 EST, Peter Robinson
no flags Details
lshal of a Thinkpad X200s with the Huawei E160G dongle plugged in (159.10 KB, application/octet-stream)
2009-03-06 18:17 EST, Bernie Innocenti
no flags Details
session log with NM_SERIAL_DEBUG=1 (30.30 KB, application/octet-stream)
2009-03-06 19:24 EST, Bernie Innocenti
no flags Details
Verbose version of lsusb (13.02 KB, text/plain)
2009-04-17 09:35 EDT, José Matos
no flags Details
Debug output of NM trying to connect the modem (6.70 KB, text/plain)
2009-04-17 09:36 EDT, José Matos
no flags Details
Corresponding entry in /var/log/messages during the same period (8.04 KB, text/x-log)
2009-04-17 09:37 EDT, José Matos
no flags Details
Debug output of NM trying to connect the modem (update) (12.85 KB, text/plain)
2009-04-17 17:30 EDT, José Matos
no flags Details
Corresponding entry in /var/log/messages during the same period (5.88 KB, text/x-log)
2009-04-17 17:31 EDT, José Matos
no flags Details

  None (edit)
Description Peter Robinson 2008-10-08 17:29:25 EDT
I've just received a huawei E160G USB 3G stick on UK provider '3'. On my eeePC 901 running F10-Beta/rawhide NM detects it fine and tries to connect but fails. Using the same SIM card in a huawei E220 (my previous/current device) on the same machine it works out of the box. The only difference is the dongle. I'll attach the /var/log/messages output in the ticket.

Also in the same release of NM (so slightly related but probably could be a different bug report) I'm seeing 3 entries of the 3G device appear in the connect list (for both the e160g and the e220). Only one connected at any one time and it was happening before I got the second dongle. Also the description for them is rather massive. Screen shot attached.
Comment 1 Peter Robinson 2008-10-08 17:31:31 EDT
Created attachment 319803 [details]
huawei e160g messages output
Comment 2 Peter Robinson 2008-10-08 17:34:30 EDT
Created attachment 319805 [details]
NM with one device listed 3 times
Comment 3 Dan Williams 2008-10-08 17:41:08 EDT
We need to some PPP debugging; to do that we need a more recent version of NetworkManager that will allow this to happen.  I'm suspecting PPP settings here at the moment that your provider doesn't like...

The listing of 3 devices in NM is due to lack of a hal-info entry for your part specifying the hardware layout of the serial ports the device advertises.  Only one is actually a AT-compatible port.
Comment 4 Peter Robinson 2008-10-08 18:09:42 EDT
OK. Let me know what's required. The provider is the same, the SIM card is the same. The E-220 works but the E-160 doesn't. Do the ppp settings change from device to device?
Comment 5 Dan Williams 2008-11-02 17:41:56 EST
Ok, so what we need to do is to stop NM, then get a root shel in the terminal and do:

NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon

then try to connect, and when it fails, grab both the output of NM from that terminal, and /var/log/messages, then attach them to this bug.  That should show us what PPP thinks went wrong.
Comment 6 Peter Robinson 2008-11-05 06:37:09 EST
Created attachment 322560 [details]
NM ddebug output

Attached is the requested NM debug output
Comment 7 Peter Robinson 2008-11-05 06:38:13 EST
Created attachment 322561 [details]
Associated dmesg output

And the associated kernel dmesg output that matches the NM debug output
Comment 8 Dan Williams 2008-11-05 08:16:02 EST
Can you add the option 'noccp' to /etc/ppp/options and comment out the others, then try?  It's a hack but we'll see if it's the:

Protocol-Reject for 'Compression Control Protocol' (0x80fd) received

or if it's the ms-dns thing.
Comment 9 Peter Robinson 2008-11-05 08:37:46 EST
the noccp option had no effect. a e220 dongle on the same machine and using the same SIM and provider work fine.
Comment 10 Bug Zapper 2008-11-25 22:41:00 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 mail 2008-12-11 03:19:06 EST
I too have this exact problem.

I thought it might have been the problem described here about NAKing wins options : http://jkroon.blogs.uls.co.za/it/networking/huawei-e220

But this made no difference.
Comment 12 Nicu Buculei 2009-01-21 02:36:24 EST
Works for me with Huawei E160E, Orange Romania and Fedora 10 with all updates applied. The only thing I had to do was to enter the APN name.
Comment 13 Dan Williams 2009-01-22 10:40:33 EST
(In reply to comment #12)
> Works for me with Huawei E160E, Orange Romania and Fedora 10 with all updates
> applied. The only thing I had to do was to enter the APN name.

Ok, thanks for the update.
Comment 14 Peter Robinson 2009-02-01 07:53:37 EST
reopening as it still doesn't work for me on 3-UK where my other Dongle does. I've never used this new dongle with Windows if that would make any difference.

output of /var/log/messages:

Feb  1 12:46:29 trinity kernel: usb 1-2: new high speed USB device using ehci_hcd and address 5
Feb  1 12:46:29 trinity kernel: usb 1-2: configuration #1 chosen from 1 choice
Feb  1 12:46:29 trinity kernel: scsi3 : SCSI emulation for USB Mass Storage devices
Feb  1 12:46:29 trinity kernel: usb 1-2: New USB device found, idVendor=12d1, idProduct=1003
Feb  1 12:46:29 trinity kernel: usb 1-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
Feb  1 12:46:29 trinity kernel: usb 1-2: Product: HUAWEI Mobile
Feb  1 12:46:29 trinity kernel: usb 1-2: Manufacturer: HUAWEI Technology
Feb  1 12:46:29 trinity kernel: usb 1-2: USB disconnect, address 5
Feb  1 12:46:30 trinity pulseaudio[2718]: module-hal-detect.c: Error getting capability: org.freedesktop.Hal.NoSuchDevice: No device with id /org/freedesktop/Hal/devices/usb_device_12d1_1003_noserial
Feb  1 12:46:30 trinity pulseaudio[2718]: module-hal-detect.c: Error getting capability: org.freedesktop.Hal.NoSuchDevice: No device with id /org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial
Feb  1 12:46:30 trinity pulseaudio[2718]: module-hal-detect.c: Error getting capability: org.freedesktop.Hal.NoSuchDevice: No device with id /org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial_scsi_host
Feb  1 12:46:35 trinity kernel: usb 1-2: new high speed USB device using ehci_hcd and address 6
Feb  1 12:46:35 trinity kernel: usb 1-2: configuration #1 chosen from 1 choice
Feb  1 12:46:35 trinity kernel: usb-storage: probe of 1-2:1.0 failed with error -5
Feb  1 12:46:35 trinity kernel: usb-storage: probe of 1-2:1.1 failed with error -5
Feb  1 12:46:36 trinity kernel: scsi6 : SCSI emulation for USB Mass Storage devices
Feb  1 12:46:37 trinity kernel: scsi7 : SCSI emulation for USB Mass Storage devices
Feb  1 12:46:37 trinity kernel: usb 1-2: New USB device found, idVendor=12d1, idProduct=1003
Feb  1 12:46:37 trinity kernel: usb 1-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
Feb  1 12:46:37 trinity kernel: usb 1-2: Product: HUAWEI Mobile
Feb  1 12:46:37 trinity kernel: usb 1-2: Manufacturer: HUAWEI Technology
Feb  1 12:46:37 trinity kernel: usbcore: registered new interface driver usbserial
Feb  1 12:46:37 trinity kernel: usbserial: USB Serial support registered for generic
Feb  1 12:46:37 trinity kernel: usbcore: registered new interface driver usbserial_generic
Feb  1 12:46:37 trinity kernel: usbserial: USB Serial Driver core
Feb  1 12:46:37 trinity kernel: usbserial: USB Serial support registered for GSM modem (1-port)
Feb  1 12:46:37 trinity kernel: option 1-2:1.0: GSM modem (1-port) converter detected
Feb  1 12:46:37 trinity kernel: usb 1-2: GSM modem (1-port) converter now attached to ttyUSB0
Feb  1 12:46:37 trinity kernel: option 1-2:1.1: GSM modem (1-port) converter detected
Feb  1 12:46:37 trinity kernel: usb 1-2: GSM modem (1-port) converter now attached to ttyUSB1
Feb  1 12:46:37 trinity kernel: usbcore: registered new interface driver option
Feb  1 12:46:37 trinity kernel: option: USB Driver for GSM modems: v0.7.2
Feb  1 12:46:37 trinity NetworkManager: <info>  ttyUSB0: driver is 'option'.
Feb  1 12:46:37 trinity NetworkManager: <info>  Found new Modem device 'ttyUSB0'.
Feb  1 12:46:37 trinity NetworkManager: <info>  (ttyUSB0): exported as /org/freedesktop/Hal/devices/usb_device_12d1_1003_noserial_if0_serial_usb_0
Feb  1 12:46:41 trinity kernel: scsi 6:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
Feb  1 12:46:41 trinity kernel: sr0: scsi-1 drive
Feb  1 12:46:41 trinity kernel: Uniform CD-ROM driver Revision: 3.20
Feb  1 12:46:41 trinity kernel: sr 6:0:0:0: Attached scsi generic sg3 type 5
Feb  1 12:46:41 trinity NetworkManager: <info>  (ttyUSB0): device state change: 1 -> 2
Feb  1 12:46:41 trinity NetworkManager: <info>  (ttyUSB0): deactivating device (reason: 2).
Feb  1 12:46:41 trinity NetworkManager: <info>  Policy set 'Auto WatchingYou' (ra0) as default for routing and DNS.
Feb  1 12:46:41 trinity NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' failed
Feb  1 12:46:41 trinity NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' failed
Feb  1 12:46:41 trinity NetworkManager: <info>  (ttyUSB0): device state change: 2 -> 3
Feb  1 12:46:42 trinity kernel: scsi 7:0:0:0: Direct-Access     HUAWEI   MMC Storage      2.31 PQ: 0 ANSI: 2
Feb  1 12:46:42 trinity kernel: sd 7:0:0:0: [sdd] Attached SCSI removable disk
Feb  1 12:46:42 trinity kernel: sd 7:0:0:0: Attached scsi generic sg4 type 0
Feb  1 12:46:56 trinity kernel: ===>rt_ioctl_giwscan. 9(9) BSS returned, data->length = 953
Feb  1 12:47:25 trinity NetworkManager: <info>  Activation (ttyUSB0) starting connection 'Auto GSM network connection'
Feb  1 12:47:25 trinity NetworkManager: <info>  (ttyUSB0): device state change: 3 -> 4
Feb  1 12:47:25 trinity NetworkManager: <info>  Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) scheduled...
Feb  1 12:47:25 trinity NetworkManager: <info>  Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) started...
Feb  1 12:47:25 trinity NetworkManager: <info>  Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) complete.
Feb  1 12:47:26 trinity NetworkManager: <info>  (ttyUSB0): powering up...
Feb  1 12:47:26 trinity NetworkManager: <info>  Registered on Home network
Feb  1 12:47:26 trinity NetworkManager: <info>  Associated with network: +COPS: 0,2,"23420",2
Feb  1 12:47:26 trinity NetworkManager: <info>  Connected, Woo!
Feb  1 12:47:26 trinity NetworkManager: <info>  Activation (ttyUSB0) Stage 2 of 5 (Device Configure) scheduled...
Feb  1 12:47:26 trinity NetworkManager: <info>  Activation (ttyUSB0) Stage 2 of 5 (Device Configure) starting...
Feb  1 12:47:26 trinity NetworkManager: <info>  (ttyUSB0): device state change: 4 -> 5
Feb  1 12:47:26 trinity NetworkManager: <info>  Starting pppd connection
Feb  1 12:47:26 trinity NetworkManager: <info>  Activation (ttyUSB0) Stage 2 of 5 (Device Configure) complete.
Feb  1 12:47:26 trinity pppd[20998]: Plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so loaded.
Feb  1 12:47:26 trinity kernel: PPP generic driver version 2.4.2
Feb  1 12:47:26 trinity pppd[20998]: pppd 2.4.4 started by root, uid 0
Feb  1 12:47:26 trinity pppd[20998]: Using interface ppp0
Feb  1 12:47:26 trinity pppd[20998]: Connect: ppp0 <--> /dev/ttyUSB0
Feb  1 12:47:26 trinity NetworkManager: <info>  (ttyUSB0): device state change: 5 -> 6
Feb  1 12:47:26 trinity pppd[20998]: CHAP authentication succeeded
Feb  1 12:47:26 trinity pppd[20998]: CHAP authentication succeeded
Feb  1 12:47:26 trinity NetworkManager: <info>  (ttyUSB0): device state change: 6 -> 7
Feb  1 12:47:28 trinity pppd[20998]: Modem hangup
Feb  1 12:47:28 trinity NetworkManager: <info>  (ttyUSB0): device state change: 7 -> 9
Feb  1 12:47:28 trinity NetworkManager: <info>  Marking connection 'Auto GSM network connection' invalid.
Feb  1 12:47:28 trinity NetworkManager: <info>  Activation (ttyUSB0) failed.
Feb  1 12:47:28 trinity NetworkManager: <info>  (ttyUSB0): device state change: 9 -> 3
Feb  1 12:47:28 trinity NetworkManager: <info>  (ttyUSB0): deactivating device (reason: 0).
Feb  1 12:47:28 trinity pppd[20998]: Connection terminated.
Feb  1 12:47:28 trinity NetworkManager: <info>  Policy set 'Auto WatchingYou' (ra0) as default for routing and DNS.
Feb  1 12:47:28 trinity NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' failed
Feb  1 12:47:28 trinity NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' failed
Feb  1 12:47:29 trinity pppd[20998]: Exit.
Comment 15 Peter Robinson 2009-02-11 12:20:50 EST
Interestingly I've never plugged this device into a windows machine (since I don't actually have one). I was at a friends place just now and happened to remember it so tested it in his windows machine and got it connected and then plugged it back into my linux laptop and it now works. Not sure what about it needs to be activated but it seems it needs windows to initialise something first. So its now working and this bug can be closed off if you don't wish to investigate the windows side of things.
Comment 16 Nicu Buculei 2009-02-12 02:46:13 EST
Mine didn't need activation in Windows, came straight from the sealed package into NetworkManager, but my device in newer and it may have a newer firmware (the firmware is user-updatable). 

My only (absolutely minor) problem is that the microSD card in it can be accessed only from Windows with some special drivers, but that is not NM related anyway.
Comment 17 Peter Robinson 2009-02-12 05:51:02 EST
I was aware of possible firmware issues. I had to do a firmware upgrade on my e220 to make that work.

On the side of the microSD card, it sort of works for me with a few issues. A 128Mb standard microSD it detects the card but a fdisk on it detects no filesystems. With a 4Gb microSDHC card it detects it all fine but doesn't automatically get mounted. A manual mount is fine. Anyway, that's out of scope for this bug. And there were some fixes for some usb SD card quirks got into 2.7.13 or 14 so it might work when the next kernel update gets pushed.
Comment 18 Dan Williams 2009-02-15 09:08:50 EST
Peter, so the E160G works OK for you now?  I've had other reports of it failing due to AT command quirks (needs AT+CGREG instead of AT+CREG to discover network registration), but it seems that's not a problem for yours.

Also just to confirm, what's the output of "/sbin/lsusb" *after* the modeswitch has happened to eject the CD-ROM?
Comment 19 Peter Robinson 2009-02-15 10:33:56 EST
Dan, Yes the E160G does now work for me once it was used in Windows.

lsusb output for the E160G is:
[root@neo ~]# lsusb
Bus 002 Device 004: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E270 HSDPA/HSUPA Modem
Comment 20 Fedora Update System 2009-02-24 15:50:18 EST
NetworkManager-0.7.0.97-5.git20090220.fc10, NetworkManager-openconnect-0.7.0.97-1.fc10, NetworkManager-pptp-0.7.0.97-1.fc10, NetworkManager-openvpn-0.7.0.97-1.fc10, NetworkManager-vpnc-0.7.0.97-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager NetworkManager-openconnect NetworkManager-pptp NetworkManager-openvpn NetworkManager-vpnc'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1985
Comment 21 Fedora Update System 2009-02-27 22:24:45 EST
NetworkManager-0.7.0.98-1.git20090225.fc10, NetworkManager-openconnect-0.7.0.97-1.fc10, NetworkManager-pptp-0.7.0.97-1.fc10, NetworkManager-openvpn-0.7.0.97-1.fc10, NetworkManager-vpnc-0.7.0.97-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager NetworkManager-openconnect NetworkManager-pptp NetworkManager-openvpn NetworkManager-vpnc'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1985
Comment 22 Bernie Innocenti 2009-03-06 12:26:53 EST
I have both the E160G and the E220 dongles, and both them managed to connect on with two service providers (tre.it and wind.it).

Howver, in all combinations of USB dongles and ISPs, establishing the connection is very unreliable: I often have to retry 2 or 3 times.  Sometimes it seems replugging the device or restarting NM helps.  I'm using kernel-2.6.27.12-170.2.5.fc10.x86_64, NetworkManager-0.7.0.98-1.git20090225.fc10.x86_64.

It might very well be bad signal or a problem of the ISP, but nm-applet does not provide any visible detail to help users diagnose the problem.
Comment 23 Fedora Update System 2009-03-06 12:35:14 EST
NetworkManager-0.7.0.99-1.fc10,knetworkmanager-0.7-0.8.20080926svn.fc10,NetworkManager-vpnc-0.7.0.99-1.fc10,NetworkManager-openvpn-0.7.0.99-1.fc10,NetworkManager-pptp-0.7.0.99-1.fc10,NetworkManager-openconnect-0.7.0.99-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.0.99-1.fc10,knetworkmanager-0.7-0.8.20080926svn.fc10,NetworkManager-vpnc-0.7.0.99-1.fc10,NetworkManager-openvpn-0.7.0.99-1.fc10,NetworkManager-pptp-0.7.0.99-1.fc10,NetworkManager-openconnect-0.7.0.99-1.fc10
Comment 24 Fedora Update System 2009-03-06 12:52:00 EST
NetworkManager-0.7.0.99-1.fc9,NetworkManager-vpnc-0.7.0.99-1.fc9,NetworkManager-openvpn-0.7.0.99-1.fc9,NetworkManager-pptp-0.7.0.99-1.fc9,NetworkManager-openconnect-0.7.0.99-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.0.99-1.fc9,NetworkManager-vpnc-0.7.0.99-1.fc9,NetworkManager-openvpn-0.7.0.99-1.fc9,NetworkManager-pptp-0.7.0.99-1.fc9,NetworkManager-openconnect-0.7.0.99-1.fc9
Comment 25 Bernie Innocenti 2009-03-06 15:22:25 EST
Fails with above version too.

I get assertion failures too:

NMgiskard:~# NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon
NetworkManager: <info>  starting...
-- Error received: File exists
-- Original message: type=0x14 length=56 flags=<REQUEST,ACK,ATOMIC> sequence-nr=1236370714 pid=4208291
NetworkManager: <WARN>  nm_generic_enable_loopback(): error -17 returned from rtnl_addr_add():
Sucess

NetworkManager: <info>  Found radio killswitch /org/freedesktop/Hal/devices/pci_8086_4236_rfkill_5300AGN_wlan
NetworkManager: <info>  (eth0): new Ethernet device (driver: 'e1000e')
NetworkManager: <info>  (eth0): exported as /org/freedesktop/Hal/devices/net_00_1f_16_0d_98_75
NetworkManager: <info>  (wlan0): driver supports SSID scans (scan_capa 0x01).
NetworkManager: <info>  (wlan0): new 802.11 WiFi device (driver: 'iwlagn')
NetworkManager: <info>  (wlan0): exported as /org/freedesktop/Hal/devices/net_00_16_ea_e4_59_a6
NetworkManager: <info>  (ttyUSB0): detected GSM modem via udev capabilities
NetworkManager: <info>  (ttyUSB0): new Modem device (driver: 'option')
NetworkManager: <info>  (ttyUSB0): exported as /org/freedesktop/Hal/devices/usb_device_1d6b_1_0000_00_1d_0_if0_0_serial_usb_0
NetworkManager: <info>  (ttyUSB1): detected GSM modem via udev capabilities
NetworkManager: <info>  (ttyUSB1): new Modem device (driver: 'option')
NetworkManager: <info>  (ttyUSB1): exported as /org/freedesktop/Hal/devices/usb_device_1d6b_1_0000_00_1d_0_if1_serial_usb_1
NetworkManager: <WARN>  killswitch_getpower_reply(): Error getting killswitch power: Method "GetPower" with signature "" on interface "org.freedesktop.Hal.Device.KillSwitch" doesn't exist
.


NetworkManager: <info>  (eth0): device state change: 1 -> 2
NetworkManager: <info>  (eth0): bringing up device.
NetworkManager: <info>  (eth0): preparing device.
NetworkManager: <info>  (eth0): deactivating device (reason: 2).
NetworkManager: <info>  (wlan0): device state change: 1 -> 2
NetworkManager: <info>  (wlan0): bringing up device.
NetworkManager: <info>  (wlan0): preparing device.
NetworkManager: <info>  (wlan0): deactivating device (reason: 2).
NetworkManager: <info>  (ttyUSB0): device state change: 1 -> 2
NetworkManager: <info>  (ttyUSB0): deactivating device (reason: 2).
NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' failed
NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' failed
NetworkManager: <info>  (ttyUSB1): device state change: 1 -> 2
NetworkManager: <info>  (ttyUSB1): deactivating device (reason: 2).
NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' failed
NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' failed
NetworkManager: <info>  (wlan0): device state change: 2 -> 3
NetworkManager: <info>  (ttyUSB0): device state change: 2 -> 3
NetworkManager: <info>  (ttyUSB1): device state change: 2 -> 3
NetworkManager: <info>  (wlan0): supplicant interface state:  starting -> ready
NetworkManager: <info>  Activation (ttyUSB0) starting connection 'Wind'
NetworkManager: <info>  (ttyUSB0): device state change: 3 -> 4
NetworkManager: <info>  Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager: <info>  Activation (ttyUSB1) starting connection 'Wind'
NetworkManager: <info>  (ttyUSB1): device state change: 3 -> 4
NetworkManager: <info>  Activation (ttyUSB1) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager: <info>  Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) started...
NetworkManager: <debug> [1236370714.268683] nm_serial_device_open(): (ttyUSB0) opening device...
NetworkManager: <info>  Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager: <info>  Activation (ttyUSB1) Stage 1 of 5 (Device Prepare) started...
NetworkManager: <debug> [1236370714.278742] nm_serial_device_open(): (ttyUSB1) opening device...
NetworkManager: <info>  Activation (ttyUSB1) Stage 1 of 5 (Device Prepare) complete.
NetworkManager: <WARN>  check_pin_done(): PIN checking failed
NetworkManager: <info>  (ttyUSB1): device state change: 4 -> 9
NetworkManager: <debug> [1236370718.002550] nm_serial_device_close(): Closing device 'ttyUSB1'
NetworkManager: <info>  Marking connection 'Wind' invalid.
NetworkManager: <info>  Activation (ttyUSB1) failed.
NetworkManager: <info>  (wlan0): device state change: 3 -> 2
NetworkManager: <info>  (wlan0): deactivating device (reason: 0).
NetworkManager: <info>  (wlan0): taking down device.
NetworkManager: <WARN>  check_pin_done(): PIN checking timed out
NetworkManager: <info>  (ttyUSB0): device state change: 4 -> 9
NetworkManager: <debug> [1236370720.070769] nm_serial_device_close(): Closing device 'ttyUSB0'
NetworkManager: <info>  Marking connection 'Wind' invalid.
NetworkManager: <info>  Activation (ttyUSB0) failed.
NetworkManager: <info>  (ttyUSB1): device state change: 9 -> 3
NetworkManager: <info>  (ttyUSB1): deactivating device (reason: 0).
NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' failed
NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' failed
NetworkManager: <info>  (ttyUSB0): device state change: 9 -> 3
NetworkManager: <info>  (ttyUSB0): deactivating device (reason: 0).
NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' failed
NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' failed
NetworkManager: <info>  Activation (ttyUSB0) starting connection 'Wind'
NetworkManager: <info>  (ttyUSB0): device state change: 3 -> 4
NetworkManager: <info>  Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager: <info>  Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) started...
NetworkManager: <debug> [1236370740.890514] nm_serial_device_open(): (ttyUSB0) opening device...
NetworkManager: <info>  Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager: <WARN>  check_pin_done(): PIN checking timed out
NetworkManager: <info>  (ttyUSB0): device state change: 4 -> 9
NetworkManager: <debug> [1236370744.151006] nm_serial_device_close(): Closing device 'ttyUSB0'
NetworkManager: <info>  Marking connection 'Wind' invalid.
NetworkManager: <info>  Activation (ttyUSB0) failed.
NetworkManager: <info>  (ttyUSB0): device state change: 9 -> 3
NetworkManager: <info>  (ttyUSB0): deactivating device (reason: 0).
NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' failed
NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' failed
Comment 26 Dan Williams 2009-03-06 16:38:20 EST
Bernie: can I get an 'lshal' dump of from your machine with your huawei plugged in?  It's likely that NM is using the wrong serial port.  The problem is that for huawei modems, we don't have good information on which of the two serial ports is the right one to use (even though they both support AT commands, only one provides the necessary CONNECT messages).  'lsusb' output from your modem would also be good.
Comment 27 Dan Williams 2009-03-06 16:47:34 EST
So if you want to narrow down the PIN problem, you can stop NM and then run it (as root) with:

NM_SERIAL_DEBUG=1 /usr/sbin/NetworkManager --no-daemon

then make the connection, and grab the output, and paste it in here.  It'll log all serial communication with the device, and will be helpful.
Comment 28 Bernie Innocenti 2009-03-06 18:17:33 EST
Created attachment 334357 [details]
lshal of a Thinkpad X200s with the Huawei E160G dongle plugged in
Comment 29 Bernie Innocenti 2009-03-06 18:24:04 EST
(In reply to comment #26)
> Bernie: can I get an 'lshal' dump of from your machine with your huawei plugged
> in?  It's likely that NM is using the wrong serial port.  The problem is that
> for huawei modems, we don't have good information on which of the two serial
> ports is the right one to use (even though they both support AT commands, only
> one provides the necessary CONNECT messages).  'lsusb' output from your modem
> would also be good.  

Yes, I have both ttyUSB0 and ttyUSB1.  Both understand hayes commands, but the second one also sends periodic status messages like this one:

^BOOT:21889908,0,0,0,76

lshal output is attached.
lsusb for the E160G says the following:

bernie@giskard:~$ sudo lsusb -v -d 12d1:1003

Bus 002 Device 073: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E270 HSDPA/HSUPA Modem
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x12d1 Huawei Technologies Co., Ltd.
  idProduct          0x1003 E220 HSDPA Modem / E270 HSDPA/HSUPA Modem
  bcdDevice            0.00
  iManufacturer           2 HUAWEI Technology
  iProduct                1 HUAWEI Mobile
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          108
    bNumInterfaces          4
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0003
  Self Powered
  Remote Wakeup Enabled
Comment 30 Bernie Innocenti 2009-03-06 19:24:51 EST
Created attachment 334372 [details]
session log with NM_SERIAL_DEBUG=1

Fails to connect twice, then it succeeds.  In the nm-applet menu, the Huawei device appears 11 times.
Comment 31 Bernie Innocenti 2009-03-06 19:25:42 EST
(In reply to comment #27)
> So if you want to narrow down the PIN problem, you can stop NM and then run it
> (as root) with:
> 
> NM_SERIAL_DEBUG=1 /usr/sbin/NetworkManager --no-daemon
> 
> then make the connection, and grab the output, and paste it in here.  It'll log
> all serial communication with the device, and will be helpful.  

Done.  Can you make sense of it?
Comment 32 Fedora Update System 2009-03-08 15:30:30 EDT
NetworkManager-0.7.0.99-1.fc9, NetworkManager-vpnc-0.7.0.99-1.fc9, NetworkManager-openvpn-0.7.0.99-1.fc9, NetworkManager-pptp-0.7.0.99-1.fc9, NetworkManager-openconnect-0.7.0.99-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 33 Fedora Update System 2009-03-08 15:32:00 EDT
NetworkManager-0.7.0.99-1.fc10, knetworkmanager-0.7-0.8.20080926svn.fc10, NetworkManager-vpnc-0.7.0.99-1.fc10, NetworkManager-openvpn-0.7.0.99-1.fc10, NetworkManager-pptp-0.7.0.99-1.fc10, NetworkManager-openconnect-0.7.0.99-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 34 Bernie Innocenti 2009-03-09 02:42:46 EDT
I had already tested 0.7.0-99-1, and it didn't solve my specific issue with the E160G and E220.

Plus, lack of user visible diagnostics for common problems makes the whole experience of using a 3G dongle a lot less pleasant.  Should I open a separate bug for this?
Comment 35 Peter Robinson 2009-03-09 05:25:26 EDT
(In reply to comment #34)
> I had already tested 0.7.0-99-1, and it didn't solve my specific issue with the
> E160G and E220.

What firmware do you have on your E220? I know some of the earlier versions of the firmware were very unstable or even unusable under linux.
Comment 36 Bernie Innocenti 2009-03-09 10:28:13 EDT
(In reply to comment #35)
> What firmware do you have on your E220? I know some of the earlier versions of
> the firmware were very unstable or even unusable under linux.  

I have updated it recently:

ATI0
Manufacturer: huawei
Model: E220
Revision: 11.117.09.00.100
IMEI: 358192012989953
+GCAP: +CGSM,+DS,+ES

OK

I have also upgraded the E160G.  Before, it would hang right after the first ATZ.
I'm surprised the Windows software could even establish a connection with that firmware.
Comment 37 José Matos 2009-04-17 09:33:26 EDT
I am not sure if this is the right place to report this. If necessary I will fill a new bug report.

I am running the latest rawhide (current):

$ yum list Network* | grep installed
NetworkManager.i586                   1:0.7.1-2.git20090414.fc11       
NetworkManager-glib.i586              1:0.7.1-2.git20090414.fc11      
NetworkManager-gnome.i586             1:0.7.1-2.git20090414.fc11      
NetworkManager-openconnect.i586       0.7.0.99-2.fc11                 
NetworkManager-openvpn.i586           1:0.7.0.99-1.fc11               
NetworkManager-pptp.i586              1:0.7.0.99-1.fc11               
NetworkManager-vpnc.i586              1:0.7.0.99-1.fc11               

I have removed the words installed in the output above for formatting reasons.

I am using a HUAWEI E160E usb dongle (that is what it says in the outer shell) modem that is identified as:

$ lsusb | grep Huawei
Bus 001 Device 010: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E270 HSDPA/HSUPA Modem

Following the same debug procedure described above I have collect the output of the verbose version of lsusb, running NetworkManager directly and the resulting entry in /var/log/messages

One further point, by inserting the GSM card in my mobile I have guaranteed that no PIN is required to activate the card.
Comment 38 José Matos 2009-04-17 09:35:25 EDT
Created attachment 340004 [details]
Verbose version of lsusb
Comment 39 José Matos 2009-04-17 09:36:22 EDT
Created attachment 340005 [details]
Debug output of NM trying to connect the modem
Comment 40 José Matos 2009-04-17 09:37:26 EDT
Created attachment 340006 [details]
Corresponding entry in /var/log/messages during the same period
Comment 41 Dan Williams 2009-04-17 09:48:19 EDT
Any idea how many contacts you have on that SIM?  Just to ensure, the SIM is properly inserted in the dongle too?
Comment 42 Peter Robinson 2009-04-17 09:59:47 EDT
I would also make sure your running a current version of the firmware
Comment 43 José Matos 2009-04-17 11:13:06 EDT
(In reply to comment #41)
> Any idea how many contacts you have on that SIM?  Just to ensure, the SIM is
> properly inserted in the dongle too?  

I have bought the dongle yesterday, and it came directly from the sealed box so I do not expect any contacts in the SIM.

Regarding the second question....

Argh, you are right. The card was badly placed, my fault. :-(

OK, now I go further:
NetworkManager: <info>  Connected, Woo!
NetworkManager: <info>  Activation (ttyUSB0) Stage 2 of 5 (Device Configure) scheduled...
NetworkManager: <info>  Activation (ttyUSB0) Stage 2 of 5 (Device Configure) starting...
NetworkManager: <info>  (ttyUSB0): device state change: 4 -> 5
NetworkManager: <info>  Starting pppd connection
NetworkManager: <debug> [1239980962.409300] nm_ppp_manager_start(): Command line: /usr/sbin/pppd nodetach lock nodefaultroute ttyUSB0 noipdefault noauth usepeerdns lcp-echo-failure 0 lcp-echo-interval 0 ipparam /org/freedesktop/NetworkManager/PPP/2 plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so
Plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so loaded.
NetworkManager: <debug> [1239980962.421598] nm_ppp_manager_start(): ppp started with pid 4282
NetworkManager: <info>  Activation (ttyUSB0) Stage 2 of 5 (Device Configure) complete.
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB0
NetworkManager: <info>  (ttyUSB0): device state change: 5 -> 6
CHAP authentication succeeded
CHAP authentication succeeded
NetworkManager: <info>  (ttyUSB0): device state change: 6 -> 7
Modem hangup
Connection terminated.
NetworkManager: <info>  (ttyUSB0): device state change: 7 -> 9
NetworkManager: <debug> [1239980963.771508] nm_serial_device_close(): Closing device 'ttyUSB0'
NetworkManager: <info>  Marking connection 'Auto Mobile Broadband (GSM) connection' invalid.
NetworkManager: <info>  Activation (ttyUSB0) failed.
NetworkManager: <info>  (ttyUSB0): device state change: 9 -> 3
NetworkManager: <info>  (ttyUSB0): deactivating device (reason: 0).
NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' failed
NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' failed
NetworkManager: <debug> [1239980966.211084] ensure_killed(): waiting for ppp pid 4282 to exit
NetworkManager: <debug> [1239980966.211260] ensure_killed(): ppp pid 4282 cleaned up
Comment 44 José Matos 2009-04-17 11:16:52 EDT
(In reply to comment #42)
> I would also make sure your running a current version of the firmware  

Where can I find further information about this?
Comment 45 Peter Robinson 2009-04-17 11:24:54 EDT
(In reply to comment #44)
> (In reply to comment #42)
> > I would also make sure your running a current version of the firmware  
> 
> Where can I find further information about this?  

There is information further up in the comments of this ticket about how to find out the firmware version. From there it depends. The firmware update would prob need to come from your carrier
Comment 46 Dan Williams 2009-04-17 11:50:55 EDT
(In reply to comment #44)
> (In reply to comment #42)
> > I would also make sure your running a current version of the firmware  
> 
> Where can I find further information about this?  

If you can get minicom running, sending "ATI" to the modem might return the information.  However, if it's currently working for you, you probably don't need a firmware update unless later on we discover further issues.
Comment 47 Dan Williams 2009-04-17 11:51:31 EDT
I do admit the SIM insertion mechanism for E160 / E169 sucks, and I got it wrong the first or second time too :)
Comment 48 José Matos 2009-04-17 17:30:16 EDT
Created attachment 340092 [details]
Debug output of NM trying to connect the modem (update)
Comment 49 José Matos 2009-04-17 17:31:53 EDT
Created attachment 340093 [details]
Corresponding entry in /var/log/messages during the same period
Comment 50 José Matos 2009-04-17 17:38:32 EDT
I have updated the debug output now with the correct position (thanks Dan).

FWIW this problem occurs in F-10 with kernel 2.6.27 and the latest from updates-testing 2.6.29.

The modem shows its presence after plugging it by flashing a green light.

The only remarkable difference is that after the connection attempt the modem has a blue light flashing while for F-10 the flashing light is green.

I am not sure what it means I am just reporting back.
Comment 51 José Matos 2009-05-12 12:42:26 EDT
As a followup I followed Peter's hint.
After inserting the dongle once in windows (really just once) and doing the install process the card just works in any F-10 and F-11 that I have tried.
It work really well, it is fast and NM "just works" (TM) immediately without any problems. Strange. :-( and :-)
Comment 52 Bernie Innocenti 2009-05-12 13:00:13 EDT
(In reply to comment #51)
> As a followup I followed Peter's hint.
> After inserting the dongle once in windows (really just once) and doing the
> install process the card just works in any F-10 and F-11 that I have tried.
> It work really well, it is fast and NM "just works" (TM) immediately without
> any problems. Strange. :-( and :-)  

Yeah, something happens in Windows that makes the dongle permanently switch into
serial mode.

Actually, I've also seen Huawei dongles randomly switching back into storage mode on Linux.  Removing and reinserting the dongle would fix it.  Weird!

Note You need to log in before you can comment on or make changes to this bug.