Bug 599930 - NetworkManager very slow in activiting GSM modem
NetworkManager very slow in activiting GSM modem
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-03 17:02 EDT by kevin
Modified: 2010-12-03 09:04 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-03 09:04:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Extract from /var/log/messages (7.76 KB, text/plain)
2010-06-03 17:02 EDT, kevin
no flags Details
modem-manager log (14.50 KB, text/plain)
2010-06-06 17:37 EDT, kevin
no flags Details
NetworkManager log (11.25 KB, text/plain)
2010-06-06 17:38 EDT, kevin
no flags Details
system log (/var/log/messages) (7.00 KB, text/plain)
2010-06-06 17:39 EDT, kevin
no flags Details
edited "lsusb -v" showing modem details (7.48 KB, text/plain)
2010-06-06 17:40 EDT, kevin
no flags Details
modem-manager log (16.61 KB, text/plain)
2010-06-29 00:12 EDT, kevin
no flags Details
NetworkManager log (12.14 KB, text/x-log)
2010-06-29 00:14 EDT, kevin
no flags Details
slightly edited syslog (10.09 KB, text/plain)
2010-06-29 00:15 EDT, kevin
no flags Details
slightly edited network-manager.log (12.13 KB, text/x-log)
2010-06-29 00:18 EDT, kevin
no flags Details
updated "lsusb -v" (7.50 KB, text/x-log)
2010-06-29 17:41 EDT, kevin
no flags Details

  None (edit)
Description kevin 2010-06-03 17:02:25 EDT
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
Comment 1 Dan Williams 2010-06-05 00:02:24 EDT
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".
Comment 2 kevin 2010-06-06 17:37:25 EDT
Created attachment 421662 [details]
modem-manager log
Comment 3 kevin 2010-06-06 17:38:21 EDT
Created attachment 421663 [details]
NetworkManager log
Comment 4 kevin 2010-06-06 17:39:18 EDT
Created attachment 421664 [details]
system log (/var/log/messages)
Comment 5 kevin 2010-06-06 17:40:15 EDT
Created attachment 421666 [details]
edited "lsusb -v" showing modem details
Comment 6 kevin 2010-06-06 17:41:26 EDT
Extra info, as requested, in attachments.

Cheers
Kevin
Comment 7 Dan Williams 2010-06-28 17:25:01 EDT
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.
Comment 8 kevin 2010-06-29 00:12:33 EDT
Created attachment 427563 [details]
modem-manager log
Comment 9 kevin 2010-06-29 00:14:35 EDT
Created attachment 427564 [details]
NetworkManager log
Comment 10 kevin 2010-06-29 00:15:17 EDT
Created attachment 427565 [details]
slightly edited syslog
Comment 11 kevin 2010-06-29 00:18:09 EDT
Created attachment 427566 [details]
slightly edited network-manager.log
Comment 12 Dan Williams 2010-06-29 14:01:33 EDT
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.
Comment 13 kevin 2010-06-29 17:41:14 EDT
Created attachment 427803 [details]
updated "lsusb -v"
Comment 14 kevin 2010-06-29 17:47:37 EDT
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?
Comment 15 Bug Zapper 2010-11-03 09:38:30 EDT
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
Comment 16 Bug Zapper 2010-12-03 09:04:58 EST
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.

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