Description of problem:
When using wireless with WEP under FC 6 one seems to need to use KEY1 instead of
KEY to make the connection work. This appears to be a simple script bug.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Enter KEY=xxxxxxxxxxxxxxxxx (key corresponding to ESSID) in
/etc/sysconfig/network-scripts/ifcfg-eth1 (or other wireless adapter)
2. ifup eth1 -- this produces failed... check cable (ha ha)
3. Change KEY= to KEY1=xxxxxxxxxxxxxxxxxxx and watch it work.
it works with KEY=
I can't reproduce this. Do you have a '1' file in /etc/sysconfig/network-scripts?
I found the source of the problem. Your comment made me suspicious of other
files in this directory and there was one called keys-eth1 with the following
If I remove this file then the problem goes away and I can use KEY=xxxx instead
of KEY1=xxxx in ifcfg-eth1. What also works is to put the actual key in this
file instead of in ifcfg-eth1 (probably the way if was intended to be used?).
Anyway, the only remaining question is where this keys-eth1 file came from.
Maybe it should be a blank file in the distro and not one with KEY= in it. (?)
It's not shipped by default. Maybe a leftover of some config tool?
Yup, it is created by the Network Configuration tool under
menu:System/Admin/Network. I just tried changing the SSID to
Auto (under the Wireless Tab) and it created the file with
KEY=(blank), so maybe that is not quite the intended behaviour?
My ifcfg-eth1 was also modified (of course) and the KEY=xxxx was
removed from there (also not so good).
Assigning to system-config-network, then.
keys are not stored in ifcfg-<iface> , they are stored in keys-<iface> by
no, blank KEY= is not intended...
Ok, but keys usually correspond to each SSID that one connects to. So shouldn't
there be KEY,ESSID pairs stored somewhere and then be matched to the output of
"iwlist eth1 scanning", or something similar? (Sorry about my ignorance of how
wireless is supposed to work under Linux, but my experience is that a lot of
playing around is required, so have patience with my comments please.)
Because of the limited possibilities ifup/ifdown has, s-c-network only
configures _one_ wireless network. For more dynamic behaviour and user
interaction, please use NetworkManager.
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.