Bug 191326 - Linksys WPC11 v.3 does not work in FC 5 (worked great FC1-4)
Linksys WPC11 v.3 does not work in FC 5 (worked great FC1-4)
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
Brian Brock
:
: 189566 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-10 16:22 EDT by zingale
Modified: 2007-11-30 17:11 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-13 14:04:29 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)
requested sysreport (384.91 KB, application/x-bzip)
2006-05-30 15:40 EDT, Lonni J Friedman
no flags Details
Command responces (8.50 KB, text/plain)
2006-06-01 00:11 EDT, Paul Thomas
no flags Details
/var/log/messages (262.40 KB, application/octet-stream)
2006-11-05 15:28 EST, Lonni J Friedman
no flags Details
/var/log/messages with hostap_cs blacklisted (347.63 KB, application/octet-stream)
2006-11-11 12:43 EST, Lonni J Friedman
no flags Details

  None (edit)
Description zingale 2006-05-10 16:22:55 EDT
Description of problem:

I am using a Linksys WPC11 v.3 PCMCIA wireless network card.  This card has
worked great under all previous version of Fedora Core, but I just updated to
FC5, and it no longer works.

In /var/log/messages, I see:

May 10 16:22:29 095-242 dhclient: wifi0: unknown hardware address type 801

/sbin/ifconfig shows:

wifi0     Link encap:UNSPEC  HWaddr 00-06-25-28-96-DD-68-EC-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:6 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:3 Base address:0x2100

note the extra 00-00-00... in the HWaddr.  This always looked fine before.

This is a clean install of FC5, not an upgrade.  Previously, my wireless card
was identified as eth1, now it seems to be wlan0 and/or wifi0 (different
applications show different ids).

I added wifi0 using system-config-network -- is there a better way to do this in
FC5?  

I understand that there should be a NetworkManager icon in my system tray, but
this does not appear -- either for the wireless or wired network.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Lonni J Friedman 2006-05-10 16:33:27 EDT
Same problem for me.  What I've discovered through alot of painful trial &
error, is that if I leave the card ejected until FC5 has fully booted, and then
insert it, networking works fine.  But if its inserted all the time while
booting, then it never works.  

I've also found that the hostap_cs driver seems to want to take ownership of the
card, and orinoco_cs (which owned it all along) fight it out.  That doesn't
really explain why it will work with being inserted post-install though.
Comment 2 Mace Moneta 2006-05-13 13:58:33 EDT
It looks like this can be addressed by adding:

# Wireless LAN card
blacklist hostap_cs

to the file /etc/modprobe.d/blacklist and 

alias wlan0 orinoco_cs

to the file /etc/modprobe.conf

It's working reliably here.
Comment 3 Lonni J Friedman 2006-05-13 14:27:26 EDT
That does not make any difference here.
Comment 4 Mace Moneta 2006-05-13 14:39:06 EDT
The problem that I was seeing is that both drivers (orinoco, hostap) were
getting loaded.  With the changes above, I show only the orinoco driver:

# lsmod | grep "orinoco\|hostap"
orinoco_cs             16900  1
orinoco                36756  1 orinoco_cs
hermes                  7680  2 orinoco_cs,orinoco

Comment 5 Lonni J Friedman 2006-05-13 15:06:43 EDT
Right, it does address that problem, however I still can't get my WPC11v3 to
work from bootup.  Only when I boot with it ejected, and then insert later does
it work.
Comment 6 zingale 2006-05-13 21:02:05 EDT
This works for me too now.  Thanks.

Haven't tried getting it working from boot-up -- that's not something I normally
try to do (I rarely boot -- usually I suspend).

Comment 7 John W. Linville 2006-05-25 14:45:51 EDT
I'm a bit confused...can this issue be closed now?

If not, please try the FC5.netdev kernels:

   http://people.redhat.com/linville/kernels/fedora-netdev/

Do those kernels work for you?
Comment 8 Lonni J Friedman 2006-05-25 14:50:27 EDT
Please don't close this, its not fixed for me with the latest FC5 kernel.  I'll
try to test a netdev kernel this weekend.  thanks
Comment 9 Geraldo Veiga 2006-05-26 11:08:57 EDT
*** Bug 189566 has been marked as a duplicate of this bug. ***
Comment 10 Lonni J Friedman 2006-05-27 21:51:39 EDT
Just tested the latest "2122" netdev kernel.  Unfortunately, there is no change
in behavior whatsoever.
Comment 11 John W. Linville 2006-05-30 14:13:21 EDT
Lonni, please attach the output of running "sysreport"...thanks!
Comment 12 Lonni J Friedman 2006-05-30 15:40:02 EDT
Created attachment 130245 [details]
requested sysreport

requested sysreport
Comment 13 Lonni J Friedman 2006-05-30 15:41:09 EDT
sysreport attached, thanks John!
Comment 14 Paul Thomas 2006-06-01 00:11:54 EDT
Created attachment 130323 [details]
Command responces
Comment 15 Paul Thomas 2006-06-01 00:14:31 EDT
I am having this same problem in FC5 with my AiroNet 350 (airo_cs). here is the
output from 
ifconfig -a 
iwconfig
tail /var/log/messages

I hope this helps in finding the problem.
Comment 16 John W. Linville 2006-08-01 14:49:37 EDT
Well it has been a while...can everyone try the current kernels at the 
location from comment 7, and post the results here...thanks!
Comment 17 Lonni J Friedman 2006-08-01 15:25:57 EDT
still broken here.
Comment 18 Dave Jones 2006-10-16 20:58:48 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 19 Lonni J Friedman 2006-10-17 22:01:26 EDT
No, this still isn't fixed.  Its sad that this bug has existed for the entire
life of FC5 and no one made any effort to work on it.
Comment 20 williamnorfleet2000 2006-11-03 14:52:29 EST
I have had exactly the same problem with an SMC2532W-B card in a Dell Inspiron
7500 under a fresh, fully updated install of FC5 (this combo worked fine under
FC3 and FC4 and the orinoco_cs driver).  Kernel is 2.6.18-1.2200.fc5.  I applied
the fixes describe in Post 2 above (thanks, Mace!).  Initially, the card would
not link with its access point when installed in the machine during booting. 
However, disabling services NetworkManager and NetworkManagerDispatcher fixed
that.  The card now works normally.  Thanks to all! 
Comment 21 Neil Horman 2006-11-03 15:16:38 EST
So I've been reading through this ticket, and the whole thing seems to be a
little lost to me.  It sounds like there are two problems being discussed in
this ticket:

1) The confusion of the hostap_cs and orinoco_cs drivers over who should be
running the wireless NIC.

2) The inability to pass traffic with cards driven by the orinoco driver coupled
with the appearance of a clearly borked MAC address.

Item (1) appears fixed by the comments in #2 and I think can be completely put
to bed at this point.  For those still having problems with (2) please configure
your syslog.conf file to record kern.debug messages and higher, then reboot the
box and try to send some traffic over your wireless link.  Then send in the
/var/log/messages file to this ticket.

Thanks!   
Comment 22 Lonni J Friedman 2006-11-03 15:33:04 EST
How does one "configure your syslog.conf file to record kern.debug messages and
higher" ?
Comment 23 Neil Horman 2006-11-03 15:45:10 EST
man syslog.conf

the details are all there.  basically you just make sure there is a line in
/etc/syslog.conf that matches this regex:
.*kern.debug.*/var/log/messages
Comment 24 Lonni J Friedman 2006-11-05 15:28:10 EST
Created attachment 140413 [details]
/var/log/messages
Comment 25 Neil Horman 2006-11-07 15:40:27 EST
well, it appears from your message logs that you haven't properly blacklisted
the hostap driver in your system, as per comment #2 (I can see that both modules
are loaded from your message log).  Please correct that and try again. 
Comment 26 Lonni J Friedman 2006-11-07 15:43:38 EST
See commment #3 where I stated that didn't help.
Comment 27 Neil Horman 2006-11-07 16:02:38 EST
That doesn't mean you don't need to do it. Orinoco and hostap are having some
sort of conflict on systems with this hardware.  Whatever else may be going on
in your system, this is certainly a problem, that we're not going to see past
without blacklisting hostap.  So please go back, blacklist the hostap driver,
and try this again.
Comment 28 Lonni J Friedman 2006-11-11 12:37:47 EST
Amazingly, after blacklisting hostap_cs the NIC works after rebooting!  This was
definitely not the case a few months ago 

I apologize for not trying it when you suggested earlier.
Comment 29 Lonni J Friedman 2006-11-11 12:42:15 EST
Actually, nevermind, its not working again after another reboot. 
/var/log/messages attached.
Comment 30 Lonni J Friedman 2006-11-11 12:43:35 EST
Created attachment 140968 [details]
/var/log/messages with hostap_cs blacklisted

/var/log/messages with hostap_cs blacklisted
Comment 31 Neil Horman 2006-11-11 13:53:49 EST
Looking at your last message log, I don't see any messages from hostap _or_
orinoco, are you sure that you didn't somehow accidentally blacklist both
drivers or something?  If you modprobe ornico by hand, does everything start
working again?
Comment 32 Lonni J Friedman 2006-11-11 16:03:41 EST
I'm 100% certain that I didn't blacklist orinoco, as its loaded, along with
orinoco_cs & hermes (in lsmod output).  As before, if I boot without the card
inserted, and then insert it once FC5 has finished booting fully, networking
comes up automatically, and there are no problems.
Comment 33 Neil Horman 2006-11-13 09:49:04 EST
I'm sorry, I must have been looking at another message log, I see orinoco
getting loaded now in your last boot.  Although I do notice that you are not on
the latest fc5 netdev kernel.  I would highly recommend updating before we go
any further with this.
Comment 34 Lonni J Friedman 2006-11-13 11:24:55 EST
I did test with a recent netdev kernel recently (and it also exhibited this
bug), unfortunately, all 2.6.18.x based kernels are pretty much unusable on this
system due to this bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214096
Comment 35 Neil Horman 2006-11-13 13:12:09 EST
well, I don't know what to tell you.  You are at this point reporting a problem
that every other reporter has fixed by following the procedure outlined in
comment #2.  At this point the only options that I see are for you to try again
with the latest driver available from linksys, and see then if the hardware
responds better (from what I read, there are several firmware updates in the
latest driver).
Comment 36 Lonni J Friedman 2006-11-13 13:25:38 EST
I'm not sure that I understand what you mean by "try again with the latest
driver available from linksys".  Do you mean the latest netdev kernel, or
something from Linksys's website?
Comment 37 Neil Horman 2006-11-13 13:44:04 EST
the latter
Comment 38 Lonni J Friedman 2006-11-13 13:46:42 EST
The 'latest' driver on Linksys's website is 3.5 years old, and doesn't even
build on a recent kernel.
Comment 39 Neil Horman 2006-11-13 14:04:29 EST
Dang, didn't check the date,  Well, I'm sorry, I don't know what to tell you. 
You are describing a problem that matches identically what at least 4 other
people in this ticket alone have described, and for each of them, the problem is
solved by blacklisting the alternate hostap driver.  I'm not sure what is
different about your particular setup, but at this point, unless you can provide
me with some other data indicating that there is another bug here, I can only
assume that there is something awry in your configuration that I can't see with
the provided data, that is causing your system to not obtain a dhcp address with
the nic plugged in from boot.
Comment 40 Lonni J Friedman 2006-11-13 14:39:46 EST
*sigh*  No offense, but I don't understand why this was closed out simply
because you can't figure out what is wrong.  I thought that bugs get closed when
there is an explanation or solution to the bug, or a lack of communication from
the bug reporter.  Neither seems to be the case here.  
There appear to be at least 4 people who have commented and/or are CC'd on this
bug who have not stated that the fix in comment #2 worked for them.

"unless you can provide me with some other data indicating that there is another
bug here"  I don't know what kind of information you need, however I get the
strong impression that you went down your checklist, and when you hit the bottom
without figuring this out, you gave up and closed the bug.  If you don't know
what the problem is here, that's fine, I can live with that, if you'd admit as
much and just let the bug sit for another 6 months.  However, closing a bug when
its clear that its not resolved just seems like the wrong approach.

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