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.
Created attachment 304332 [details] entire messages file
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
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.
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
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!
(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
Created attachment 304580 [details] logs from a failed attempt to connect to a GSM Network
Created attachment 304581 [details] logs from a successful connection to a GSM Network
Ok; thanks for the trace. This bug has been fixed upstream in svn r3628.
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
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?
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.
Same issues with 3675. Backrev'ing to the versions from Preview allow my card to work.
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
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
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.
This bug has been triaged -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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
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.