Red Hat Bugzilla – Bug 872278
Huawei E173 not working after update
Last modified: 2014-06-09 21:56:04 EDT
Created attachment 636754 [details]
Config files and log output of livecd and updated OS when connecting to Huawei 3G E173 Modem
Description of problem:
Connection failed after update. Working properly on Installation LiveCD.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run Fedora (i386,x86_64) LiveCD.
2. Connect Modem Huawei E173
3. Configure Network using NetworkManager wizzard
4. Connections works
5. Update system packages (yum update/upgrade)
6. Connection fails
7. Remove and create new configuration using wizzard.
8. Connection fails
Running from livecd, or after installation, the modem works fine. After OS update, fails to connect.
There are differences between usb_modeswitch configuration file regarding this specific modem, 12d1:1c0b (lsusb). But using the older config it still doesn't work
Created attachment 647944 [details]
modem manager: successful connect w HUAWEI 173
Created attachment 647946 [details]
modem manager: failed connect attempt HUAWEI 173
pls excuse comment vs attachment ordering in BZ. grrr.
ModemManager fails for me too (Huawei 173)
USB modeswitch is OK, pin number is accepted.
ModemManager-0.6.0.0-1.fc17.x86_64 does not connect
ModemManager-0.5.3.96-1.fc17.x86_64 works OK
the following actions were covered by the logs:
* plug in modem
* enter pin
* enable broadband in KDE NM applet
* try to connect
(fortunately I had a local copy of ModemManager-0.5.3.96 while traveling...)
Created attachment 753129 [details]
Logs from failed connection
Here the same problem, Huawi E173 modem stopped to work after upgrade to Fedora 16 -> 18.
I can however connect using wvdial with config below:
Init1 = ATZ
Modem Type = Analog Modem
ISDN = 0
Phone = *99#
Modem = /dev/ttyUSB0
Username = internet
Password = internet
Baud = 460800
Auto DNS = on
Check DNS = on
Check Def Route = on
Logs of unsuccesfull connection with NM included as attachements
Created attachment 753131 [details]
Logs from failed connection - NM (debug mode)
NetworkManager log (debug mode)
Created attachment 753133 [details]
snippet from /var/log/messages
Bus 002 Device 018: ID 12d1:1c08 Huawei Technologies Co., Ltd.
ttyUSB in the system:
[root@xeno Xeno]# ls /dev/ttyUSB*
[root@xeno Xeno]# ls /dev/ttyUSB* -l
crw-rw----. 1 root dialout 188, 0 05-25 19:26 /dev/ttyUSB0
crw-rw----. 1 root dialout 188, 1 05-25 19:26 /dev/ttyUSB1
I tried to bisect this issue. I was forced to do some bisect-skip, but managed to get suspected commits:
The first bad commit could be any of:
4dad94d5004f325e25dc3b09d87585eab38d4c3f core: rework port grabbing and organization
30e706309462f6b207753209649143902ee538fa iridium: convert to new port grabbing scheme
I think most likely the first one. Can anyone more experienced with git verify my finds?
Created attachment 753258 [details]
ModemManager - PINless card failed conection.
After more thorough inspection I fount that first ModemManager log contains fail due SIMcad PIN (it seems thare's another problem, because I provided it twice 9in connection properities and into PIN request pop-up upon inserting modem into USB port).
This log is from PIN-disabled card failed connection.
Created attachment 753259 [details]
ModemManager - PINless card successful conection.
ModemManager log from succesfull connection (ModemManager-5.3.96)
Stan, looks like in the bad log MM is using ttyUSB1 as the dial port, but it's supposed to use ttyUSB0 instead. Thus dialing fails. This is because the modem lies about its configuration:
modem-manager: <debug> [1369562498.222875] [mm-at-serial-port.c:334] debug_log(): (ttyUSB0): <-- 'MODE<CR><CR><LF>^GETPORTMODE: TYPE: WCDMA: huawei,NDIS:0,PCUI:1,GPS:2<CR><LF><CR><LF>OK<CR><LF>'
which means the modem is telling us that port 0 is supposed to be a network interface, not a serial port, and so ModemManager assumes that the device is telling the truth. This code was added to correctly handle other Huawei devices which do have network ports.
I believe this was fixed a while back in the MM stable branch, I'll do a snapshot of that for Fedora.
ModemManager-0.6.0.0-4.git20130528.fc17 has been submitted as an update for Fedora 17.
ModemManager-0.6.0.0-4.git20130528.fc18 has been submitted as an update for Fedora 18.
ModemManager-0.6.0.0-4.git20130528.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ModemManager-0.6.0.0-4.git20130528.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
ModemManager-0.6.2.0-1.fc19 has been submitted as an update for Fedora 19.
ModemManager-0.6.2.0-1.fc18 has been submitted as an update for Fedora 18.
ModemManager-0.6.2.0-1.fc17 has been submitted as an update for Fedora 17.
ModemManager-0.6.2.0-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
ModemManager-0.6.2.0-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
ModemManager-0.6.2.0-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.