Bug 436212 - CDMA card support in NM doesn't work (yet)
CDMA card support in NM doesn't work (yet)
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-05 17:04 EST by Ulrich Drepper
Modified: 2008-08-02 19:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-07 23:17:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ulrich Drepper 2008-03-05 17:04:15 EST
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:
Comment 1 Dan Williams 2008-03-05 17:54:17 EST
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?
Comment 2 Dan Williams 2008-03-05 18:32:10 EST
Also, could you state the full version of NetworkManager you have installed,
including the ".svnXXXX" number?  Thanks!
Comment 3 Ulrich Drepper 2008-03-05 18:35:26 EST
(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
Comment 4 Ulrich Drepper 2008-03-05 18:53:50 EST
(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?
Comment 5 Ulrich Drepper 2008-03-05 19:07:25 EST
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.
Comment 6 Dan Williams 2008-03-05 19:14:05 EST
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?
Comment 7 Ulrich Drepper 2008-03-05 19:23:38 EST
(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.
Comment 8 Ulrich Drepper 2008-03-09 22:46:48 EDT
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?
Comment 9 Dan Williams 2008-03-18 12:22:37 EDT
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?
Comment 10 Bug Zapper 2008-05-14 01:47:50 EDT
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 Brennan Ashton 2008-06-07 23:17:54 EDT
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.

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