Bug 438756 - kernel - iwl3945 fails association with AP
Summary: kernel - iwl3945 fails association with AP
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 8
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-03-24 21:26 UTC by Milos Jakubicek
Modified: 2008-05-06 12:08 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-05-05 19:20:05 UTC
Type: ---

Attachments (Terms of Use)
dmesg output (29.11 KB, text/plain)
2008-03-24 21:26 UTC, Milos Jakubicek
no flags Details
Another dmesg output on a different network. (46.93 KB, text/plain)
2008-03-26 13:31 UTC, Milos Jakubicek
no flags Details
dmesg output with (33.99 KB, text/plain)
2008-03-31 12:03 UTC, Milos Jakubicek
no flags Details
Output of "iwlist wlan0 freq" on kernel- (1.12 KB, text/plain)
2008-05-03 13:36 UTC, Milos Jakubicek
no flags Details
Output of "iwlist wlan0 freq" on kernel- (724 bytes, text/plain)
2008-05-03 13:37 UTC, Milos Jakubicek
no flags Details
modprobe.conf (354 bytes, text/plain)
2008-05-05 19:04 UTC, Milos Jakubicek
no flags Details

Description Milos Jakubicek 2008-03-24 21:26:50 UTC
Description of problem:

On kernel, the iwl3945 driver fails association with AP. See the
attached dmesg output. When I try to
setup the connection manually (i.e. I stop the NM and type "ifup wlan0"), I get:

Error for wireless request "Set Encode" (8B2A) :
    SET failed on device wlan0 ; No such file or directory.

I didn't touch anything manually, except that after an upgrade to I
renamed wlan0_rename back to wlan0 (under /etc/sysconfig/...).

The last working (concerning wireless) kernel for me is still

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

How reproducible:

Just boot up, try to setup the wifi either by NM or manually as described.
Actual results:

The association request is timed out.

Expected results:

It will associate to the AP, get IP address...work:)

Comment 1 Milos Jakubicek 2008-03-24 21:26:50 UTC
Created attachment 298953 [details]
dmesg output

Comment 2 John W. Linville 2008-03-25 13:32:52 UTC
Please attach the output of "iwlist wlan0 scan", and of "iwconfig wlan0".  

Comment 3 Milos Jakubicek 2008-03-26 13:30:53 UTC
>iwlist wlan0 scan
wlan0     No scan results

>iwconfig wlan0
wlan0     IEEE 802.11  ESSID:"wlan_fi"
          Mode:Managed  Frequency:2.442 GHz  Access Point: 00:02:2D:1B:42:F6
          Bit Rate=11 Mb/s   Tx-Power=15 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Link Quality=68/100  Signal level=-65 dBm  Noise level=-127 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

!!! I've tried this on a different network (cannot do it today on the same as
when filing this bug) and checked also the dmesg output which is quite different
-- there is some additional info, so I attach this dmesg too.

Thank you in advance!

Comment 4 Milos Jakubicek 2008-03-26 13:31:37 UTC
Created attachment 299145 [details]
Another dmesg output on a different network.

Comment 5 John W. Linville 2008-03-26 19:32:43 UTC
Honestly, it looks like you have wpa_supplicant and NetworkManager fighting 
over control of your wireless device.  Please make sure that the 
wpa_supplicant server is not running -- NetworkManager will start its own copy 
as necessary.

   service wpa_supplicant stop
   chkconfig wpa_supplicant off

You probably want to make sure NetworkManager is set to start automatically as 

   chkconfig NetworkManager on

Also, make sure to run system-config-network and make sure "Activate device 
when computer starts" is _not_ selected for your wireless devices.  Be sure to 
save the configuration when quitting system-config-network!

After completing the steps above (as root, of course) then please reboot.  Is 
your wireless connection behaving better now?

Comment 6 Milos Jakubicek 2008-03-27 23:24:33 UTC
I'm afraid it's not the case.
wpa_supplicant is (and has ever been) disabled:

>chkconfig --list wpa_supplicant
wpa_supplicant  0:off   1:off   2:off   3:off   4:off   5:off   6:off

NM is enabled:

>chkconfig --list NetworkManager
NetworkManager  0:off   1:off   2:off   3:on    4:on    5:on    6:off

"Activate device when computer starts" has not been selected.
However, "Controlled by NM" has also not been selected -- I've selected it,
saved, reboot, no change.

If I can supply any additional debug information, just let me know. Maybe a
dmesg from the working kernel?

Comment 7 John W. Linville 2008-03-28 13:35:26 UTC
Please post the contents of your /etc/modprobe.conf.

The iwconfig output in comment 3 shows an association.  Is this problem 
intermittent?  Does it depend on the type of encryption involved?  Could there 
just be a weak signal?

When you have problems, could you try 'modprobe -r iwl3945 ; modprobe 
iwl3945' -- does that change things?

Comment 8 Milos Jakubicek 2008-03-31 12:02:33 UTC
>Please post the contents of your /etc/modprobe.conf.

alias scsi_hostadapter ata_piix
alias scsi_hostadapter1 ahci
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0
remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; };
/sbin/modprobe -r --ignore-remove snd-hda-intel

# added by kvpnc, do not edit it.
alias ppp-compress-18 ppp_mppe
alias eth0 sky2

>The iwconfig output in comment 3 shows an association.  Is this problem 

I don't think so: I tried it many times, it has never suceeded.

>Does it depend on the type of encryption involved?

I don't know since none of the networks I've tested uses encryption. 

>Could there just be a weak signal?

Surely no (tested 3 networks, in 2 of them the distance between my laptop and
the AP was < 5m).

>When you have problems, could you try 'modprobe -r iwl3945 ; modprobe 
>iwl3945' -- does that change things?

That's what I try everytime (sometimes also restarting NM after rmmod&modprobe
helps), in this case without any success.

But I have to correct myself concerning the latest working kernel: I found out
that works for me, but only before suspend&resume to RAM. After STR
it works in about 25% of cases (and it will be surely a completely different
problem as usually in STR issues). When I tested this kernel before, I didn't
realize that my laptop has been resumed from RAM before, sorry for that.

So I tried all the kernels after and here is what I found out. - works, sometimes also after STR - N/A (Koji build failed) - works, works after STR & rmmod & modprobe - works like a charm, even after STR! - N/A (not in Koji) - N/A (not in Koji) - NEVER works (again, association timed out)

So probably the problem is between the release 7 and 10.
I also posted dmesg from, though I doubt there will be any new

Comment 9 Milos Jakubicek 2008-03-31 12:03:51 UTC
Created attachment 299713 [details]
dmesg output with

Comment 10 Milos Jakubicek 2008-03-31 12:26:28 UTC
Just see that even has a small issue -- it's not possible to bring up
the wifi manually as "ifup wlan0" results in:

>ifup wlan0
Error for wireless request "Set Mode" (8B06) :
    SET failed on device wlan0 ; Invalid argument.

Comment 11 John W. Linville 2008-04-08 19:51:42 UTC
Please try


Does that work any better for you?

Comment 12 Milos Jakubicek 2008-04-12 00:01:16 UTC
Sorry for late answer,

I Tested -64, -69, -74 with no success. But the problem seems to depend on what
 AP is used as I found a network where I CAN connect with no problems with these
kernels. Currently I know the results from following AP's:

Asus WL-550gE (works)
Ovislink WL-5460AP (does NOT work)
D-Link DAP-1160 (does NOT work)

I also tested on f9 (on another partition, fresh install f9 beta and update to
latest rawhide) with the Ovislink, it didn't work too.

Is there any way how to further debug these things on those non-working AP's?

Comment 13 Milos Jakubicek 2008-04-13 08:26:27 UTC
One more AP notice:
Ovislink WT-2000R with WPA PSK works...

Comment 14 Milos Jakubicek 2008-04-13 17:08:35 UTC
Today I tried kernel-2.6.25-0.224.rc9.fc9.x86_64 and it works perfectly with
both of the previously non-working AP's. Looking into its changelog, I see:

* Sat Apr 12 2008 Chuck Ebbert <cebbert@redhat.com>
- 2.6.25-rc9
- Temporarily disabled wireless patches.

I guess this is why it works now:) Please could you review these patches,
especially those added between the and when it stopped
working for me?

Comment 15 Milos Jakubicek 2008-04-27 22:51:19 UTC
Fine, after reenabling the patches, it didn't work again (as expected), but now
the D-link works with both kernel-2.6.25-10.fc9.x86_64 on rawhide/F9 and
kernel- on F8. On wednesday I'll be able to test also the
Ovislink AP, if it will work, I'll be happy to be able to close this bug:)

Comment 16 John W. Linville 2008-04-29 20:33:50 UTC
I look forward to your report! :-)

Comment 17 Milos Jakubicek 2008-05-01 22:46:56 UTC
Sorry for a small delay and bad news: I'm very sorry but with the Ovislink it
still doesn't work. Neither it doesn't see the network (i.e. "iwlist wlan0 scan"
doesn't show it), nor it is listed in the output from "iwconfig wlan0".

Just to be sure that there is no other problem, I tried (again) to connect to
that network with kernel- and with another laptop which has an Atheros
and uses the madwifi driver, both solutions work fine.

Comment 18 John W. Linville 2008-05-02 03:26:17 UTC
Not showing up in "iwconfig wlan0" cannot be related to the AP.  Are you sure 
it the driver is loaded?

Comment 19 Milos Jakubicek 2008-05-03 13:35:40 UTC
OK, I think I've found the reason -- the network runs on channel 13 which has
been obviously disabled in the driver. I've attached the outputs from "iwlist
wlan0 freq" ( and, please look at the
differences. This explains, why I can connect with kernel- without any
problems, but don't see the network with kernel- -- after
changing the channel on the AP to 10, I can connect too.
Is there any reason why some of the channels are disabled now or is it just a bug?

Comment 20 Milos Jakubicek 2008-05-03 13:36:55 UTC
Created attachment 304453 [details]
Output of "iwlist wlan0 freq" on kernel-

Comment 21 Milos Jakubicek 2008-05-03 13:37:19 UTC
Created attachment 304454 [details]
Output of "iwlist wlan0 freq" on kernel-

Comment 22 John W. Linville 2008-05-05 14:37:38 UTC
The kernel defaults to the US regulatory domain, which excludes channel 13.  
The only other regulatory domain the kernel currently knows about is for Japan 
("JP"), which you can select in /etc/modprobe.conf:

   options cfg80211 ieee80211_regdom="JP"

Please ensure that you do not use any wireless configuration disallowed by 
local regulations.

BTW, there used to be a similar option for the mac80211 module.  The related 
functionality got moved to cfg80211.  Perhaps you already have a similar 
option in modprobe.conf?  That would explain why older kernels work for you.

Comment 23 Milos Jakubicek 2008-05-05 19:02:43 UTC
No, I don't think my modprobe.conf contains something related (see attached).

If it is by default set to US regulatory domain constraints, then it seems to be
a bug for me, because I've found following regulatory domain constraints which
differ a lot:

USA (FCC): Channels 1-11
Canada (IC): Channels 1-11
Europe (ETSI): Channels 1-13
Japan (TELEK): Channels 1-13
Japan (MKK): Channel 14
France: Channels 10-13
Spain: Channels 10-11

In Europe we have some additional constraints, as mentioned e.g. here:
"The channels that are available for use in a particular country differ
according to the regulations of that country. In the United States, for example,
FCC regulations only allow channels 1 through 11 to be used. In Europe channels
1-13 are licensed for 802.11b operation but only allow lower transmitted power
(only 100 mW) to reduce the interference with other ISM band users."

Moreover, if I've understood it right, then according to IEEE 802.11d standard
it should be possible to determine current regulatory constraints runtime, is it
not implemented yet?

Anyway, restricting some channels apriori doesn't seem to be a good idea for me
(just notice that on that AP channel 13 has been preset as default from
factory!), as it may really confuse users (like I was) when they do not see
their network at all:)

It could be also probably worth investigating why older kernels worked for me,
i.e. where is the change.

But this is definitely a completely different problem, so I'll file a new bug, ok?

I'm also changing the state to MODIFIED and assume that you'll set this bug to
be autoclosed when a new update will be pushed.
Thanks for all the work!

Comment 24 Milos Jakubicek 2008-05-05 19:04:11 UTC
Created attachment 304548 [details]

Comment 25 John W. Linville 2008-05-05 19:20:05 UTC
Actually setting it to MODIFIED makes it drop off my radar.  I'm going to go 
ahead and close it as NOTABUG as it is actually working as currently designed, 
even if the current design is a bit flawed. :-)

There are plans to implement a more flexible regulatory scheme upstream, but 
it is not yet implemented.

Comment 26 Milos Jakubicek 2008-05-05 20:01:49 UTC
Eh...sorry for bothering you with one more post: ok, but we're mixing two
different things together:

- the first problem concerns the failing association with D-Link AP. This is
FIXED, CURRENTRELEASE ( and higher, in my experience).

- the second concerns the regulatory stuff, it's NOTABUG in respect to your
previous comment.

I've just one more question: wouldn't it be better to completely DISABLE this
regulatory constraints until it will be implemented properly?! Again: it can
prevent users from using their wireless connection.

The very simple fix might be to set "options cfg80211 ieee80211_regdom="JP" by
default -- if it doesn't have any side-effects.

Comment 27 Milos Jakubicek 2008-05-05 20:08:18 UTC
FYI: http://permalink.gmane.org/gmane.linux.kernel.wireless.general/13803

If it really depends on you as mentioned, then here is a tiny unimportant vote
for it:)

Comment 28 John W. Linville 2008-05-06 12:08:44 UTC
Something has to be the default and from a legal perspective it is probably 
better to default to not doing something you are allowed to do than the other 
way around.

As for the "EU" domain, it is still under consideration.  Apparently not all 
of the EU is under ETSI's jurisdiction, so there was some objection to the 
naming.  Also there is still the hope of moving to regulatory policing done in 

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