Red Hat Bugzilla – Bug 599930
NetworkManager very slow in activiting GSM modem
Last modified: 2010-12-03 09:04:58 EST
Created attachment 420454 [details] Extract from /var/log/messages Description of problem: After plugging in a GSM modem it takes NetworkManager / ModemManager over two minutes to start pppd. The modem is actually usable much sooner as a manually started pppd succeeds. Version-Release number of selected component (if applicable): egrep -i '(modem|network)manager' /var/log/rpmpkgs NetworkManager-vpnc-0.7.996-4.git20090921.fc12.x86_64 NetworkManager-glib-0.8.0-6.git20100408.fc12.x86_64 NetworkManager-openconnect-0.7.996-4.git20090921.fc12.x86_64 NetworkManager-gnome-0.8.0-6.git20100408.fc12.x86_64 NetworkManager-0.8.0-6.git20100408.fc12.x86_64 NetworkManager-openvpn-0.7.996-4.git20090923.fc12.x86_64 NetworkManager-pptp-0.7.997-3.git20100120.fc12.x86_64 ModemManager-0.3-9.git20100409.fc12.x86_64 How reproducible: Plug GSM modem in and wait Steps to Reproduce: as above Actual results: See attachment Expected results: pppd started after less than 30 seconds Additional info: none
Can you try the debugging tips here under "Debugging NetworkManager 0.8 3G Connections" to grab a modem-manager --debug log for me? Then we can really see what the device is actually doing. http://live.gnome.org/NetworkManager/Debugging my first thought is that your modem (what specific model is it?) doesn't report its status correctly, but still as "searching for network".
Created attachment 421662 [details] modem-manager log
Created attachment 421663 [details] NetworkManager log
Created attachment 421664 [details] system log (/var/log/messages)
Created attachment 421666 [details] edited "lsusb -v" showing modem details
Extra info, as requested, in attachments. Cheers Kevin
It appears this is because you've filled in the "Network ID" box in the connection editor with "50501", which causes the modem to re-search for your operator. If you can remove that option and get another log from modem-manager, and report how long the connection takes in that case, that would be great. If you're trying to make sure the device doesn't roam recent versions of NM and MM have options to stop roaming when the modem reports that it's on a partner network.
Created attachment 427563 [details] modem-manager log
Created attachment 427564 [details] NetworkManager log
Created attachment 427565 [details] slightly edited syslog
Created attachment 427566 [details] slightly edited network-manager.log
What kind of ZTE modem is this? I ask this because: ** (modem-manager:30688): DEBUG: <1277783836.581836> (ttyUSB2): <-- '<CR><LF>+CPMS: "SM",0,10,"SM",0,10,"ME",1,100<CR><LF><CR><LF>OK<CR><LF>' ** Message: (ttyUSB1) opening serial device... ** (modem-manager:30688): DEBUG: <1277783851.581832> (ttyUSB1) device open count is 1 (open) this indicates a pause of about 25 seconds that happens when the serial port is opened, and I've seen this with specific devices that are driven by the 'option' driver. This is caused by interactions between the device and the driver and not really by ModemManager. It looks like that's the case for opening every single port. I have an MF622, an MF636, and a random Reliance India CDMA ZTE device (2627?) and only the 2627 exhibits strange behavior like this, except it blocks for 20 seconds when closing ports.
Created attachment 427803 [details] updated "lsusb -v"
It's a "636" Please see the updated "lsusb -v" attachment. The F13 version shows that info (and other extras?) whereas the F12 didn't. Oh, yes, since logging this report I've updated to F13, but the same problem still exists. So this indeed point to an NetworkManager or ModemManager problem. But, then again,... I agree that there is a lot of opening and closing of serial ttyUSBx ports. Is the driver searching for the actual modem port?
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.