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
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
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
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):
Steps to Reproduce:
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.
It looks like this can be addressed by adding:
# Wireless LAN card
to the file /etc/modprobe.d/blacklist and
alias wlan0 orinoco_cs
to the file /etc/modprobe.conf
It's working reliably here.
That does not make any difference here.
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
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
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).
I'm a bit confused...can this issue be closed now?
If not, please try the FC5.netdev kernels:
Do those kernels work for you?
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
*** Bug 189566 has been marked as a duplicate of this bug. ***
Just tested the latest "2122" netdev kernel. Unfortunately, there is no change
in behavior whatsoever.
Lonni, please attach the output of running "sysreport"...thanks!
Created attachment 130245 [details]
sysreport attached, thanks John!
Created attachment 130323 [details]
I am having this same problem in FC5 with my AiroNet 350 (airo_cs). here is the
I hope this helps in finding the problem.
Well it has been a while...can everyone try the current kernels at the
location from comment 7, and post the results here...thanks!
still broken here.
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.
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.
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!
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
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.
How does one "configure your syslog.conf file to record kern.debug messages and
the details are all there. basically you just make sure there is a line in
/etc/syslog.conf that matches this regex:
Created attachment 140413 [details]
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.
See commment #3 where I stated that didn't help.
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.
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.
Actually, nevermind, its not working again after another reboot.
Created attachment 140968 [details]
/var/log/messages with hostap_cs blacklisted
/var/log/messages with hostap_cs blacklisted
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
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.
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.
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:
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
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?
The 'latest' driver on Linksys's website is 3.5 years old, and doesn't even
build on a recent kernel.
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.
*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.