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.
Created attachment 319803 [details] huawei e160g messages output
Created attachment 319805 [details] NM with one device listed 3 times
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.
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?
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.
Created attachment 322560 [details] NM ddebug output Attached is the requested NM debug output
Created attachment 322561 [details] Associated dmesg output And the associated kernel dmesg output that matches the NM debug output
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.
the noccp option had no effect. a e220 dongle on the same machine and using the same SIM and provider work fine.
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
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.
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.
(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.
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.
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.
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.
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.
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?
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
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
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
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.
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
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
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
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.
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.
Created attachment 334357 [details] lshal of a Thinkpad X200s with the Huawei E160G dongle plugged in
(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
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.
(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?
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.
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.
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?
(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.
(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.
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.
Created attachment 340004 [details] Verbose version of lsusb
Created attachment 340005 [details] Debug output of NM trying to connect the modem
Created attachment 340006 [details] Corresponding entry in /var/log/messages during the same period
Any idea how many contacts you have on that SIM? Just to ensure, the SIM is properly inserted in the dongle too?
I would also make sure your running a current version of the firmware
(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
(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?
(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
(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.
I do admit the SIM insertion mechanism for E160 / E169 sucks, and I got it wrong the first or second time too :)
Created attachment 340092 [details] Debug output of NM trying to connect the modem (update)
Created attachment 340093 [details] Corresponding entry in /var/log/messages during the same period
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.
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 :-)
(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!