Bug 444911 - Can no longer connect w/ 'Auto GSM' after updating to 0.7.0-0.9.3.svn3623.fc9 co
Summary: Can no longer connect w/ 'Auto GSM' after updating to 0.7.0-0.9.3.svn3623.fc9 co
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-01 18:45 UTC by Chris Van Hoof
Modified: 2023-08-21 15:06 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-14 16:55:03 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
entire messages file (957.02 KB, application/octet-stream)
2008-05-01 18:45 UTC, Chris Van Hoof
no flags Details
logs from a failed attempt to connect to a GSM Network (3.61 KB, text/plain)
2008-05-06 00:15 UTC, Chris Van Hoof
no flags Details
logs from a successful connection to a GSM Network (4.02 KB, text/plain)
2008-05-06 00:16 UTC, Chris Van Hoof
no flags Details

Description Chris Van Hoof 2008-05-01 18:45:50 UTC
Description of problem:
I initially installed Fedora Preview which shipped w/ 0.7.0-0.9.2.svn3566.fc9. 
I was able to plug in my Option GT Max 3.6 Express card, and automatically
connect to a 3G network via Network Manager.  

After updating today (5/1/2008) The icon spins endlessly (two dots, both grey),
and when clicking the icon the entire X session hangs.

Ejecting the card will return my X session.  A service NetworkManager restart
also stops the lockup.


Version-Release number of selected component (if applicable):
0.7.0-0.9.3.svn3623.fc9 == not working
0.7.0-0.9.2.svn3566.fc9 == working

How reproducible:
Easily, plugin card, and select Auto GSM connection

Steps to Reproduce:
1. Plugin card
2. Select Auto GSM connection
3. Wait for a while :)
  
Actual results:
If you try to click on the applet, X will lock up  (although logs still print in
an active gnome-terminal session tail'ing /var/log/messages. 

No connection is established.


Expected results:

Connection to 3G network


Additional info:

Grabbing all the NetworkManager-* packages from Fedora 9 Preview, and running
rpm -Uvh Network-Manager-*.x86_64.*.rpm --oldpackage, and a reboot fixed the issue.

I see in the changelog there has been some recent work to fix a potential race
condition when dealing with these cards, perhaps that has something to do with this.

I'll attach the logs from my failed (and successful) connections.

Comment 1 Chris Van Hoof 2008-05-01 18:45:50 UTC
Created attachment 304332 [details]
entire messages file

Comment 2 Chris Van Hoof 2008-05-01 18:50:43 UTC
FAILED CONNECTION:

May  1 14:19:02 localhost NetworkManager: <info>  Activation (ttyUSB0) starting
connection 'Auto GSM network connection'
May  1 14:19:02 localhost NetworkManager: <info>  (ttyUSB0): device state
change: 3 -> 4
May  1 14:19:02 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 1
of 5 (Device Prepare) scheduled...
May  1 14:19:02 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 1
of 5 (Device Prepare) started...
May  1 14:19:02 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 1
of 5 (Device Prepare) complete.
May  1 14:19:02 localhost NetworkManager: <info>  Registered on Home network
May  1 14:19:02 localhost NetworkManager: <info>  Associated with network:
+COPS: 0,0,"AT&T",2
May  1 14:19:33 localhost NetworkManager: <WARN>  nm_signal_handler(): Caught
signal 15, shutting down normally.
May  1 14:19:37 localhost NetworkManager: <info>  starting...

I waited ~30 seconds before issuing a service NetworkManager restart


Comment 3 Chris Van Hoof 2008-05-01 18:53:11 UTC
SUCCESSFUL CONNECTION (after downgrading):

May  1 14:28:26 localhost NetworkManager: <info>  Activation (ttyUSB0) starting
connection 'Auto GSM network connection'
May  1 14:28:26 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 1
of 5 (Device Prepare) scheduled...
May  1 14:28:26 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 1
of 5 (Device Prepare) started...
May  1 14:28:26 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 1
of 5 (Device Prepare) complete.
May  1 14:28:26 localhost NetworkManager: <info>  Registered on Home network
May  1 14:28:26 localhost NetworkManager: <info>  Associated with network:
+COPS: 0,0,"AT&T",2
May  1 14:28:26 localhost NetworkManager: <info>  Connected, Woo!
May  1 14:28:26 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 2
of 5 (Device Configure) scheduled...
May  1 14:28:26 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 2
of 5 (Device Configure) starting...
May  1 14:28:26 localhost NetworkManager: <info>  Starting pppd connection
May  1 14:28:26 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 2
of 5 (Device Configure) complete.
May  1 14:28:26 localhost pppd[3176]: Plugin
/usr/lib64/pppd/2.4.4/nm-pppd-plugin.so loaded.
May  1 14:28:26 localhost kernel: PPP generic driver version 2.4.2
May  1 14:28:26 localhost pppd[3176]: pppd 2.4.4 started by root, uid 0
May  1 14:28:26 localhost pppd[3176]: Using interface ppp0
May  1 14:28:26 localhost pppd[3176]: Connect: ppp0 <--> /dev/ttyUSB0
May  1 14:28:26 localhost NetworkManager: <WARN> 
impl_ppp_manager_need_secrets(): Cleared secrets, but setting didn't need any
secrets.
May  1 14:28:26 localhost kernel: PPP Deflate Compression module registered
May  1 14:28:27 localhost console-kit-daemon[2330]: WARNING: Couldn't read
/proc/2954/environ: Error reading file '/proc/2954/environ': No such process
May  1 14:28:30 localhost pppd[3176]: Could not determine remote IP address:
defaulting to 10.64.64.64
May  1 14:28:30 localhost pppd[3176]: local  IP address 166.214.71.182
May  1 14:28:30 localhost pppd[3176]: remote IP address 10.64.64.64
May  1 14:28:30 localhost pppd[3176]: primary   DNS address 209.183.35.23
May  1 14:28:30 localhost pppd[3176]: secondary DNS address 209.183.33.23
May  1 14:28:30 localhost NetworkManager: <info>  PPP manager(IP Config Get)
reply received.
May  1 14:28:30 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 4
of 5 (IP Configure Get) scheduled...
May  1 14:28:30 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 4
of 5 (IP Configure Get) started...
May  1 14:28:30 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 5
of 5 (IP Configure Commit) scheduled...
May  1 14:28:30 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 4
of 5 (IP Configure Get) complete.
May  1 14:28:30 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 5
of 5 (IP Configure Commit) started...
May  1 14:28:30 localhost NetworkManager: <WARN> 
nm_system_device_set_from_ip4_config(): (ppp0) error -17 returned from
rtnl_addr_add():#012Missing link name TLV (errno = Invalid argument)
May  1 14:28:31 localhost NetworkManager: <info>  Policy set (wlan0) as default
device for routing and DNS.
May  1 14:28:31 localhost NetworkManager: <info>  Activation (ttyUSB0)
successful, device activated.
May  1 14:28:31 localhost NetworkManager: <info>  Activation (ttyUSB0) Stage 5
of 5 (IP Configure Commit) complete.
May  1 14:29:38 localhost NetworkManager: <info>  Deactivating device ttyUSB0.

I was up and running for about a minute, and then I successfully disconnected.

Comment 4 Chris Van Hoof 2008-05-01 18:55:09 UTC
This card did require me to log use a tool shipped w/ the card (ran on a Mac),
to set the number, username, and password.  I plugged it into a Mac, and all of
those settings are still in-tact, and the card works properly now on a Mac, and
F9 w/ the original Preview release of NM.

--chris

Comment 5 Dan Williams 2008-05-02 14:46:34 UTC
Could you try the following with svn3623 (all as root):

service NetworkManager stop
/usr/sbin/NetworkManager --no-daemon
<try to connect to GSM>

then recover from a hang (kill the NM process or eject the card or whatever you
need to do) and attach the output from the terminal in which you ran NM?  That
will log the serial communication with the card which I'll need to diagnose this
issue.  Thanks!

Comment 6 Chris Van Hoof 2008-05-06 00:14:41 UTC
(In reply to comment #5)
> Could you try the following with svn3623 (all as root):
> 
> service NetworkManager stop
> /usr/sbin/NetworkManager --no-daemon
> <try to connect to GSM>
> 
> then recover from a hang (kill the NM process or eject the card or whatever you
> need to do) and attach the output from the terminal in which you ran NM?  That
> will log the serial communication with the card which I'll need to diagnose this
> issue.  Thanks!

Here it is -- It was a bit hard to kill off the failed NM session, I had to
switch to a VT, and kill it by hand.

nm_not_working.txt == svn3623
nm_working.txt == svn3566

All I did, was start up NM, and select the Auto GSM option in the dropdown.

--chris



Comment 7 Chris Van Hoof 2008-05-06 00:15:53 UTC
Created attachment 304580 [details]
logs from a failed attempt to connect to a GSM Network

Comment 8 Chris Van Hoof 2008-05-06 00:16:35 UTC
Created attachment 304581 [details]
logs from a successful connection to a GSM Network

Comment 9 Dan Williams 2008-05-06 13:33:16 UTC
Ok; thanks for the trace.  This bug has been fixed upstream in svn r3628.

Comment 10 Bug Zapper 2008-05-14 10:29:41 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Edmond 2008-06-07 02:05:54 UTC
I am having the same problem on Fedora 9 actual with a SE GC83 GPRS/EDGE modem
card. Is this problem now fixed? or Maybe this device is not support?

Comment 12 Dan Williams 2008-06-09 17:54:39 UTC
Edmond, can you try the packages here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=51684

they should fix your problem.  If they don't, let me know.

Comment 13 Chris Van Hoof 2008-06-16 17:24:48 UTC
Same issues with 3675.  Backrev'ing to the versions from Preview allow my card
to work.

Comment 14 Edmond 2008-06-18 05:14:14 UTC
Hi Dan,

I tried the 3675, the same problem. Here's the steps:

1) install the rpm
2) add GPRS connection in Network connections -> Mobile broadband, click and
check connect automatically
3) insert the GC83 w/ SIM inserted

dmesq show this:
...
...
...
pccard: PCMCIA card inserted into slot 0
cs: memory probe 0xe4300000-0xe7ffffff: excluding 0xe4300000-0xe46cffff
0xe4e70000-0xe523ffff 0xe5db0000-0xe617ffff 0xe6cf0000-0xe70bffff
pcmcia: registering new device pcmcia0.0
0.0: ttyS2 at I/O 0x3e8 (irq = 3) is a 16550A

Comment 15 Chris Van Hoof 2008-07-09 02:39:59 UTC
Hey Dan -- Is there anything else I can provide you to assist here?  Nothing
beyond svn3623 works with this card.

I tested another laptop, installed Fedora Preview, everything worked.  Updated
to current, and the problems surface again.

--chris

Comment 17 Dan Williams 2008-11-02 21:56:37 UTC
Is this still an issue with latest NM updates in F8 (svn4022) or rawhide?  If so, we'll do a bit more manual debugging to figure out what's going wrong.

Comment 18 Jessica Sterling 2009-03-08 19:30:30 UTC
This bug has been triaged

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 19 Bug Zapper 2009-06-10 00:33:38 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 '9'.

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 9'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 9 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 20 Bug Zapper 2009-07-14 16:55:03 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.