Description of problem: Trying to use a CDMA card with the rawhide has multiple problems. Because I hav eno idea what the state of the code base is I'm not filing separate bugs. Maybe all this is known. The problems include: - clicking on the CDMA entry causes other connections (wireless) to be dropped - the modem is actually not successfully used. It's not blinking (although once I got that far but it still didn't work) - when the NM is brought up again while the CDMA is not successfully initialized the applet hangs. Since it currently has the focus the entire desktop becomes unusable - sometimes this hang times out. Then the NM applet image is not updated anymore (it shows the two unlit LED images) In its current form the CDMA code is a real danger. I very much appreciate the progress but this needs to be fixed or support disabled before the release. Version-Release number of selected component (if applicable): NetworkManager-0.7.0-0.8 How reproducible: always Steps to Reproduce: 1.insert CDMA card 2.select entry from NM menue 3. Actual results: See above Expected results: established connection Additional info:
Will try to address the issues individually... First, what CDMA card do you have? lspci or lspcmcia information would be great. As a general note, it's been working quite solidly for at least 3 people including myself using CDMA cards. - "clicking on the CDMA entry causes other connections (wireless) to be dropped" This is the currently expected behavior until multiple device support is finished, which is what I'm working on right now. - "the modem is actually not successfully used" Is there a status light on the card at all, and what color is that light? For example, the Sierra card I've got blinks Red when disconnected, and green when it's registered. Also, can you provide an 'lshal' dump for your card so I can verify that the correct serial port is tagged as a modem? If the wrong serial port is tagged, then NM won't be able to execute AT commands on the interface since that interface doesn't implement the AT command set. Can you attach /var/log/messages for this case? - "when the NM is brought up again while the CDMA is not successfully initialized the applet hangs." Could you attach the contents of /var/log/messages when this situation occurs?
Also, could you state the full version of NetworkManager you have installed, including the ".svnXXXX" number? Thanks!
(In reply to comment #1) > - "the modem is actually not successfully used" > > Is there a status light on the card at all, and what color is that light? When the card is inserted and the USB ports are registered etc a blue LED is on. > For > example, the Sierra card I've got blinks Red when disconnected, and green when > it's registered. This card blinks its one blue LED in case the connection is established. > Also, can you provide an 'lshal' dump for your card so I can > verify that the correct serial port is tagged as a modem? If the wrong serial > port is tagged, then NM won't be able to execute AT commands on the interface > since that interface doesn't implement the AT command set. See bug 436211, it has the lshal output. > Can you attach /var/log/messages for this case? Also included in bug 436211 > - "when the NM is brought up again while the CDMA is not successfully > initialized the applet hangs." > > Could you attach the contents of /var/log/messages when this situation occurs? I'll try that later. (In reply to comment #1) > Also, could you state the full version of NetworkManager you have installed, > including the ".svnXXXX" number? NetworkManager-0.7.0-0.8.svn3370.fc9.x86_64
(In reply to comment #1) > - "when the NM is brought up again while the CDMA is not successfully > initialized the applet hangs." > > Could you attach the contents of /var/log/messages when this situation occurs? It hand also happens if you just remove the card. Mind you, the connection wasn't successful, only one of the LEDs are lit. Eventually the machine becomes responsive again. I then inserted the card again, the /var/log/messages are the same you get when inserting the card for the first time, and the interface freezes again. One noteworthy thing: the second time the USB devices used are USB[345678] instead of the usual USB[012345]. I see USB[012] still in /dev, maybe NM hangs on to file descriptors?
A few more tests later, I can now connect with the press of a button. The problem is that SELinux gets in the way (I disabled enforcement for the test). Without enforcement everything is set up correctly. The SELinux issue is that pppd wants to write something to system_bus_socket (presumably /var/run/dbus/system_bus_socket). I'll file a separate bug for that. What this means for the problems mentioned in this bug is that likely some error paths are not cleaning up after themselves. I.e., if pppd fails the system is left in a state it doesn't expect and all kinds of bad things happen.
Thanks for the investigation; I likely do need to ensure the error paths are clean. I'm going to run a bunch of test with SELinux in enforcing mode soon to see if I can't clear some of these up. Please make sure you cc dwalsh on the SELinux bugs too. It's actually a NetworkManager pppd plugin (/usr/lib/pppd/2.4.4/nm-pppd-plugin.so) that uses dbus to communicate the returned PPP config information back to NetworkManager. Should this bug be closed then and the remaining issues refiled in others?
(In reply to comment #6) > Please make sure you cc dwalsh on the SELinux bugs too. It's actually a > NetworkManager pppd plugin (/usr/lib/pppd/2.4.4/nm-pppd-plugin.so) that uses > dbus to communicate the returned PPP config information back to NetworkManager. The bug is assigned to Dan (bug 436229). It's not a problem in pppd since we don't distribute its policy in that RPM. > Should this bug be closed then and the remaining issues refiled in others? You're the judge. If you don't need a reminder of the cleanup work you might as well close the bug. It just quite important to do this since if for other reasons pppd fails (and it does quite often, depending on where one is) the system is in a bad state.
OK, some more problems. With the current SElinux policy it all initially works. The interface comes up. But when I disconnect, the nm-applet becomes unresponsive. Even worse, when I then remove the CDMA card at least the entire UI freezes (maybe the entire machine, I have no other machines here to ping the laptop). What info do you need and how can I collect it?
Hmm; can you gdb NM itself and get a backtrace when the applet freezes? Or as root, stop NM, run it with "--no-daemon" and redirect the output to somewhere. Then pull the card, get it to freeze, reboot, and attach the log?
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
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.