Bug 244179

Summary: iwl3945 driver doesn't works in fedora 7
Product: [Fedora] Fedora Reporter: Deependra Singh Shekhawat <jeevanullas>
Component: kernelAssignee: John W. Linville <linville>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Brian Brock <bbrock>
Severity: urgent Docs Contact:
Priority: low    
Version: 7CC: cebbert, chris.brown, davej, fedora, jjerome1, matt, pauljohn
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-13 20:29:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Log of failed association to WPA hidden AP, with subsequent association after manually specifying the ESSID none

Description Deependra Singh Shekhawat 2007-06-14 12:39:51 UTC
Description of problem:
In-built driver for intel 3945 wireless named iwl3945 doesn't work in Fedora 7
final release.

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

Kernel release 
Linux localhost.localdomain 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 15:37:31 EDT
2007 i686 i686 i386 GNU/Linux

Driver release
version:        0.0.24kd

Steps to Reproduce:
1. Boot a freshly install fedora 7 non-xen kernel.
2. Update to the latest available kernel. That is 2.6.21-1.3228.fc7.
3. Reboot the system into the newly installed kernel.
4. In system-config-network edit the wlan0 device. Settings to be made:
a) Activate device on boot up.
b) Obtain IP address setting from dhcp
c) Automatically obtain DNS setting from provider
d) Mode : Master
e) Network SSID specified: BSNL
f) Channel: 1 (Default)
g) Transmit Rate : Auto (Default)
h) Key (Hex key): 0x94CBA4E101D32E9AE2BE100251 (WEP)

Save the settings. And for better results reboot.

5). Gnome starts. Network manager also starts. After a one minute delay it
founds the access points. Ask to give a password to the keyring. After giving
the keyring password. It tries to connect to the access point. After about 5
minutes it starts asking for Wireless Internet security key. On providing the
128bit hex key it again ask about the same after some time. Keep asking about
the key and never connects.

6) Seeing the dmesg tells
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux,
0.0.24kd
iwl3945: Copyright(c) 2003-2007 Intel Corporation
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:03:00.0 to 64
iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:1b.0 to 64
si3054: cannot initialize. EXT MID = 0000
iwl3945: Channel 12 [2.4GHz] is Tx only -- skipping.
iwl3945: Channel 13 [2.4GHz] is Tx only -- skipping.
iwl3945: Channel 14 [2.4GHz] is Tx only -- skipping.
iwl3945: Channel 183 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 184 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 185 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 187 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 188 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 189 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 192 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 196 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 7 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 8 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 11 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 12 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 16 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 34 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 38 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 42 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 46 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 100 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 104 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 108 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 112 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 116 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 120 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 124 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 128 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 132 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 136 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 140 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 145 [5.2GHz] is Tx only -- skipping.
iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels
wmaster0: Selected rate control algorithm 'iwl-3945-rs'
iwl3945: REPLY_ADD_STA failed
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:30:bd:c5:91:8e
wlan0: authenticate with AP 00:30:bd:c5:91:8e
wlan0: authenticate with AP 00:30:bd:c5:91:8e
wlan0: authentication with AP 00:30:bd:c5:91:8e timed out


It should have connected I guess. But this kernel disappoints too. Any comments
on this ? The ipw3945 is working though.

Thanks

Comment 1 John W. Linville 2007-06-14 13:20:04 UTC
You should use either system-config-network OR NetworkManager, but not both.

If you want to use NetworkManager, you should run system-config-network one 
more time and set it to NOT activate the device on boot.

If you want to use system-config-network, then you should probably "chkconfig 
NetworkManager off" to keep NetworkManager from interfering with your static 
configuration.

FWIW, with the 3219 kernel NetworkManager finds my local WEP network and 
connects just fine...YMMV...

When you settle on either NetworkManager or system-config-network (but not 
both), do you see better results?

Comment 2 John W. Linville 2007-06-14 13:39:37 UTC
Oh, one other thing...if you stick with system-config-network then be sure to 
use "Managed" mode rather than "Master" mode...the latter is only for when you 
want the box to act as an AP...

Comment 3 Deependra Singh Shekhawat 2007-06-14 13:45:25 UTC
Okay I disabled the device to get activated on boot via system-config-network.
So now only Network Manager is in picture. Right ?

I rebooted and via Network manager created a new wireless network connection.
This is what I got in /var/log/messages

Jun 14 19:09:28 localhost NetworkManager: <info>  Creating network 'BSNL' on
device '/org/freedesktop/NetworkManager/Devices/wlan0'. 
Jun 14 19:09:28 localhost dhcdbd: message_handler: message handler not found
under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.reason
Jun 14 19:09:28 localhost NetworkManager: <info>  Device wlan0 activation
scheduled... 
Jun 14 19:09:28 localhost NetworkManager: <info>  Activation (wlan0) started... 
Jun 14 19:09:28 localhost NetworkManager: <info>  Activation (wlan0) Stage 1 of
5 (Device Prepare) scheduled... 
Jun 14 19:09:28 localhost NetworkManager: <info>  Activation (wlan0) Stage 1 of
5 (Device Prepare) started... 
Jun 14 19:09:28 localhost NetworkManager: <info>  Activation (wlan0) Stage 2 of
5 (Device Configure) scheduled... 
Jun 14 19:09:28 localhost NetworkManager: <info>  Activation (wlan0) Stage 1 of
5 (Device Prepare) complete. 
Jun 14 19:09:28 localhost NetworkManager: <info>  Activation (wlan0) Stage 2 of
5 (Device Configure) starting... 
Jun 14 19:09:28 localhost NetworkManager: <info>  Activation (wlan0/wireless):
access point 'BSNL' is unencrypted, no key needed. 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: sending command
'INTERFACE_ADD wlan0             wext    /var/run/wpa_supplicant ' 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: response was 'OK' 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: sending command 'AP_SCAN 2' 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: response was 'OK' 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: sending command
'ADD_NETWORK' 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: response was '0' 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: sending command
'SET_NETWORK 0 ssid 42534e4c' 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: response was 'OK' 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: sending command
'SET_NETWORK 0 mode 1' 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: response was 'OK' 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: sending command
'SET_NETWORK 0 key_mgmt NONE' 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: response was 'OK' 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: sending command
'ENABLE_NETWORK 0' 
Jun 14 19:09:29 localhost NetworkManager: <info>  SUP: response was 'OK' 
Jun 14 19:09:29 localhost NetworkManager: <info>  Activation (wlan0) Stage 2 of
5 (Device Configure) complete. 
Jun 14 19:09:49 localhost NetworkManager: <info>  Activation (wlan0/wireless):
association took too long (>20s), failing activation. 
Jun 14 19:09:49 localhost NetworkManager: <info>  Activation (wlan0) failure
scheduled... 
Jun 14 19:09:49 localhost NetworkManager: <info>  Activation (wlan0) failed for
access point (BSNL) 
Jun 14 19:09:49 localhost NetworkManager: <info>  Activation (wlan0) failed. 
Jun 14 19:09:49 localhost NetworkManager: <info>  Deactivating device wlan0. 
Jun 14 19:09:50 localhost NetworkManager: <info>  nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0 


It still doesn't connects.
Can you comment on this ?


Comment 4 John W. Linville 2007-06-14 14:29:21 UTC
It looks like you turned-off WEP.  Is this intentional (i.e. did you disable 
it at the AP as well)?

The iwl3945 driver seems to sometimes take a little too long to assoc, 
especially on the first try.  Did you try again?

How far away is your AP?  The iwl3945 driver seems to need a fairly strong 
signal.

If NetworkManager still fails to connect, disable it:

   service NetworkManager stop # 'chkconfig NetworkManager off' for permanent

Then try a manual configuration:

   killall dhclient
   ifconfig wlan0 up
   iwlist wlan0 scan
   # 'iwconfig wlan0 key <WEP key>' if you are still using WEP
   iwconfig wlan0 essid BSNL
   dhclient wlan0

Does this produce a working connection?

Comment 5 Deependra Singh Shekhawat 2007-06-14 14:47:41 UTC
No WEP is still on.

I tried many times but never got a association.

AP is about 30 meters away.

Network manager never worked so I did the above.

[root@localhost ~]# ifconfig wlan0 up
[root@localhost ~]# iwlist wlan0 scan
wlan0     Scan completed :
          Cell 01 - Address: 00:30:BD:C5:91:8E
                    ESSID:"BSNL"
                    Mode:Master
                    Channel:8
                    Frequency:2.447 GHz
                    Quality=84/100  Signal level=-49 dBm  
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
                    Extra:tsf=00000006949c8cb4

[root@localhost ~]# iwconfig wlan0 enc "94CBA4E101D32E9AE2BE100251"
[root@localhost ~]# iwconfig wlan0 essid "BSNL"
[root@localhost ~]# dhclient wlan0
Internet Systems Consortium DHCP Client V3.0.5-RedHat
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
wmaster0: unknown hardware address type 801
wmaster0: unknown hardware address type 801
Listening on LPF/wlan0/00:13:02:4b:70:05
Sending on   LPF/wlan0/00:13:02:4b:70:05
Sending on   Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 19
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

Couldn't get a DHCP address from the router. I tried to find if DHCP is running
and found that it was running.


Later a iwconfig showed that the wireless was associated with the access point.
But ip address was not set.

[root@localhost ~]# ping 192.168.2.1
connect: Network is unreachable
[root@localhost ~]# iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

wmaster0  no wireless extensions.

wlan0     IEEE 802.11g  ESSID:"BSNL"  
          Mode:Managed  Frequency:2.447 GHz  Access Point: 00:30:BD:C5:91:8E   
          Retry min limit:7   RTS thr:off   Fragment thr=2346 B   
          Encryption key:94CB-A4E1-01D3-2E9A-E2BE-1002-51
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0


So now ?
What should I do ?



Comment 6 Joe Jerome 2007-06-18 01:43:08 UTC
We have an Asus Z96FM laptop (Verified By Intel) with Fedora 7 installed using
the KDE LiveCD.  Wireless won't turn on.  Our dmesg listing similar to
Deependra's.  Using system-config-network shows the wlan0 inactive.  Clicking
'Activate' returns an error dialog saying 'Cannot activate network device wlan0!
 Device wlan0 does not seem to be present, delaying installation.  Don't know if
this is the same bug!  Should I send more info to this bug report, or open
another case?

Comment 7 Matthew Truch 2007-06-22 22:30:40 UTC
I am having similar problems.  Here's my info (and what I did).  Please let me
know if this is an unrelated bug (or something I'm doing stupid).  

My machine is a Dell D620 with F7 and all updates as of this post.  

[root@tbc ~]# rpm -q kernel
kernel-2.6.21-1.3194.fc7
kernel-2.6.21-1.3228.fc7
[root@tbc ~]# cat /proc/version
Linux version 2.6.21-1.3228.fc7 (kojibuilder.redhat.com) (gcc
version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Tue Jun 12 15:37:31 EDT 2007
[root@tbc ~]# rpm -q NetworkManager
NetworkManager-0.6.5-5.fc7
[root@tbc ~]# chkconfig --list network
network         0:off   1:off   2:on    3:off   4:off   5:off   6:off
[root@tbc ~]# runlevel
N 5

If I try and connect to an access point (no WEP, AP is about 2 m away), I get
the following in /var/log/messages:

Jun 22 18:23:33 tbc NetworkManager: <info>  User Switch:
/org/freedesktop/NetworkManager/Devices/wlan0 / woodrow
Jun 22 18:23:33 tbc NetworkManager: <info>  Deactivating device wlan0.
Jun 22 18:23:33 tbc dhcdbd: message_handler: message handler not found under
/com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.reason
Jun 22 18:23:33 tbc NetworkManager: <info>  Device wlan0 activation scheduled...
Jun 22 18:23:33 tbc NetworkManager: <info>  Activation (wlan0) started...
Jun 22 18:23:33 tbc NetworkManager: <info>  Activation (wlan0) Stage 1 of 5
(Device Prepare) scheduled...
Jun 22 18:23:33 tbc NetworkManager: <info>  Activation (wlan0) Stage 1 of 5
(Device Prepare) started...
Jun 22 18:23:33 tbc NetworkManager: <info>  Activation (wlan0) Stage 2 of 5
(Device Configure) scheduled...
Jun 22 18:23:33 tbc NetworkManager: <info>  Activation (wlan0) Stage 1 of 5
(Device Prepare) complete.
Jun 22 18:23:33 tbc NetworkManager: <info>  Activation (wlan0) Stage 2 of 5
(Device Configure) starting...
Jun 22 18:23:33 tbc NetworkManager: <info>  Activation (wlan0/wireless): access
point 'woodrow' is unencrypted, no key needed.
Jun 22 18:23:34 tbc NetworkManager: <info>  SUP: sending command 'INTERFACE_ADD
wlan0           wext    /var/run/wpa_supplicant '
Jun 22 18:23:34 tbc NetworkManager: <info>  SUP: response was 'OK'
Jun 22 18:23:34 tbc NetworkManager: <info>  SUP: sending command 'AP_SCAN 1'
Jun 22 18:23:34 tbc NetworkManager: <info>  SUP: response was 'OK'
Jun 22 18:23:34 tbc NetworkManager: <info>  SUP: sending command 'ADD_NETWORK'
Jun 22 18:23:34 tbc NetworkManager: <info>  SUP: response was '0'
Jun 22 18:23:34 tbc NetworkManager: <info>  SUP: sending command 'SET_NETWORK 0
ssid 776f6f64726f77'
Jun 22 18:23:34 tbc NetworkManager: <info>  SUP: response was 'OK'
Jun 22 18:23:34 tbc NetworkManager: <info>  SUP: sending command 'SET_NETWORK 0
key_mgmt NONE'
Jun 22 18:23:34 tbc NetworkManager: <info>  SUP: response was 'OK'
Jun 22 18:23:34 tbc NetworkManager: <info>  SUP: sending command 'ENABLE_NETWORK 0'
Jun 22 18:23:34 tbc NetworkManager: <info>  SUP: response was 'OK'
Jun 22 18:23:34 tbc NetworkManager: <info>  Activation (wlan0) Stage 2 of 5
(Device Configure) complete.
Jun 22 18:23:54 tbc NetworkManager: <info>  Activation (wlan0/wireless):
association took too long (>20s), failing activation.
Jun 22 18:23:54 tbc NetworkManager: <info>  Activation (wlan0) failure scheduled...
Jun 22 18:23:54 tbc NetworkManager: <info>  Activation (wlan0) failed for access
point (woodrow)
Jun 22 18:23:54 tbc NetworkManager: <info>  Activation (wlan0) failed.
Jun 22 18:23:54 tbc NetworkManager: <info>  Deactivating device wlan0.
Jun 22 18:23:55 tbc NetworkManager: <info>  nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0
Jun 22 18:23:55 tbc NetworkManager: <info>  nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0
Jun 22 18:24:04 tbc kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jun 22 18:24:04 tbc NetworkManager: <info>  nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0

If I follow your suggestions above (disabling NetworkManager and trying
manually) it fails when I try the iwlist scan operation (although I try to go
further): 

[root@tbc ~]# service NetworkManager stop
Stopping NetworkManager daemon:                            [  OK  ]
[root@tbc ~]# killall dhclient
dhclient: no process killed
[root@tbc ~]# ifconfig wlan0 up
[root@tbc ~]# iwlist wlan0 scan
wlan0     Failed to read scan data : Resource temporarily unavailable

[root@tbc ~]# iwlist wlan0 scan
wlan0     Failed to read scan data : Resource temporarily unavailable

[root@tbc ~]# lsmod |grep 3945
iwl3945               157221  0
mac80211              145609  1 iwl3945
[root@tbc ~]# iwconfig wlan0 essid woodrow
[root@tbc ~]# dhclient wlan0
[root@tbc ~]# iwconfig wlan0
wlan0     IEEE 802.11a  ESSID:"woodrow"
          Mode:Managed  Frequency:5.18 GHz  Access Point: Not-Associated
          Retry min limit:7   RTS thr:off   Fragment thr=2346 B
          Encryption key:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

[root@tbc ~]# ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 00:1B:77:18:9D:0B
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)



Comment 8 Matthew Truch 2007-06-26 12:01:56 UTC
Well, something weird is going on.  When I'm at work, my laptop connects to the
wireless just fine (it is WEP encrypted).  When I'm at home, where the AP is
open, I cannot connect (the logs from above are from when I'm home).  

Comment 9 John W. Linville 2007-07-13 15:51:24 UTC
Please try the kernels from here:

   http://koji.fedoraproject.org/koji/buildinfo?buildID=10941

Do they work any better for you?

Comment 10 Paul Johnson 2007-07-20 04:47:51 UTC
Comment #8 matches my experience exactly!  How surprising.  I am using the
newest test kernel (kernel-2.6.22.1-27.fc7) and firmware from updates testing
(iwlwifi-firmware-2.14.4-1). The iwl3945 does associate with a WEP encrypted
network, but on open & unsecured 80211b networks in coffee shops, the iwl3945
churns and fails, but the ipw3945 driver (with the binary daemon ipw3945d) does
succeed.   I am pasting in the dmesg info from a time when it failed to join an
open network:
 
ACPI: PCI interrupt for device 0000:0c:00.0 disabled
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux,
0.0.36kd
iwl3945: Copyright(c) 2003-2007 Intel Corporation
ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:0c:00.0 to 64
iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
iwl3945: Unhandled INTA bits 0x04000000
iwl3945: Disabled INTA bits 0x04000000 were pending
iwl3945:    with FH_INT = 0x00000000
iwl3945: Channel 12 [2.4GHz] is Tx only -- skipping.
iwl3945: Channel 13 [2.4GHz] is Tx only -- skipping.
iwl3945: Channel 14 [2.4GHz] is Tx only -- skipping.
iwl3945: Channel 183 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 184 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 185 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 187 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 188 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 189 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 192 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 196 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 7 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 8 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 11 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 12 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 16 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 34 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 38 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 42 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 46 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 100 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 104 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 108 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 112 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 116 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 120 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 124 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 128 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 132 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 136 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 140 [5.2GHz] is Tx only -- skipping.
iwl3945: Channel 145 [5.2GHz] is Tx only -- skipping.
iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels
wmaster0: Selected rate control algorithm 'iwl-3945-rs'
iwl3945: REPLY_ADD_STA failed
eth1: Initial auth_alg=0
eth1: authenticate with AP 00:0f:b5:51:7f:2c
eth1: RX authentication from 00:0f:b5:51:7f:2c (alg=0 transaction=2 status=0)
eth1: authenticated
eth1: associate with AP 00:0f:b5:51:7f:2c
eth1: invalid aid value 0; bits 15:14 not set
eth1: RX AssocResp from 00:0f:b5:51:7f:2c (capab=0x5 status=18 aid=0)
eth1: AP denied association (code=18)
eth1: associate with AP 00:0f:b5:51:7f:2c
eth1: invalid aid value 0; bits 15:14 not set
eth1: RX AssocResp from 00:0f:b5:51:7f:2c (capab=0x5 status=18 aid=0)
eth1: AP denied association (code=18)
eth1: associate with AP 00:0f:b5:51:7f:2c
eth1: invalid aid value 0; bits 15:14 not set
eth1: RX AssocResp from 00:0f:b5:51:7f:2c (capab=0x5 status=18 aid=0)
eth1: AP denied association (code=18)
eth1: association with AP 00:0f:b5:51:7f:2c timed out
iwl3945: REPLY_ADD_STA failed
eth1: Initial auth_alg=0
eth1: authenticate with AP 00:0f:b5:51:7f:2c
eth1: RX authentication from 00:0f:b5:51:7f:2c (alg=0 transaction=2 status=0)
eth1: authenticated
eth1: associate with AP 00:0f:b5:51:7f:2c
eth1: invalid aid value 0; bits 15:14 not set
eth1: RX AssocResp from 00:0f:b5:51:7f:2c (capab=0x5 status=18 aid=0)
eth1: AP denied association (code=18)
eth1: associate with AP 00:0f:b5:51:7f:2c
eth1: invalid aid value 0; bits 15:14 not set
eth1: RX AssocResp from 00:0f:b5:51:7f:2c (capab=0x5 status=18 aid=0)
eth1: AP denied association (code=18)
eth1: associate with AP 00:0f:b5:51:7f:2c
eth1: invalid aid value 0; bits 15:14 not set
eth1: RX AssocResp from 00:0f:b5:51:7f:2c (capab=0x5 status=18 aid=0)
eth1: AP denied association (code=18)
eth1: association with AP 00:0f:b5:51:7f:2c timed out


Comment 11 John W. Linville 2007-07-20 13:49:28 UTC
Regarding comment 10, the AP is denying your association.  It appears to be a 
mismatch in supported rates.  This is not obviously a driver problem, as it 
could be a misconfiguration of the AP.

Do you get similar logs at other open APs?

Comment 12 Paul Johnson 2007-07-22 18:15:23 UTC
Answering comment 11, Yes, I will get info from other APs with the iwl3945
driver.   

But I wonder if you are missing one detail in asking. The ipw3945 driver does
associate to that particular AP, without any trouble.  Remove that and try the
iwl3945--then association fails.

But I'll do more tests and report back

Comment 13 Russell Harrison 2007-07-24 12:11:14 UTC
The latest kernel and firmware do have the iwlwifi drivers working with my 3945
when I authenticate to my WEP network at home.  However, I'm still unable to
authenticate to the hidden network at work using WPA-EAP PEAP TKIP.  I'm still
getting an error that "association took too long"

Comment 14 Matthew Truch 2007-07-30 20:39:08 UTC
Even with the kernels from comment 9, as well as the most recent kernels for FC
7 (2.6.22.1-33.fc7) I am still unable to connect to the wireless at home (which
ipw3945 could connect to without problems, as well as a test windows machine). 
This is the case with either WEP enabled or disabled (I've tried both).  Are
there any more details I can provide that will help solve this?

Comment 15 John W. Linville 2007-07-31 12:40:10 UTC
Matthew, et al.,

Is "ESSID Broadcast" _dis_abled on the networks that are giving you trouble?  
Have/Can you try enabling it?  Does that help?

Comment 16 Matthew Truch 2007-07-31 13:39:02 UTC
(In reply to comment #15)
> Is "ESSID Broadcast" _dis_abled on the networks that are giving you trouble?  
> Have/Can you try enabling it?  Does that help?

ESSID Broadcast has always been enabled for the network in question. 
NetworkManager sees the network (as does iwlist scan when I tested things
without NetworkManager).  

Comment 17 Josh Miller 2007-09-06 20:08:51 UTC
Hi John,

I believe I have the same problem, with slightly different kernel/driver
configuration.

Fedora 7
kernel:  2.6.22.1-41.fc7
driver:  iwl3945-firmware-2.14.1.5-1
wpa_supplicant:  wpa_supplicant-0.5.7-3.fc7

The symptoms that I see are:
1. associates using WEP to AP whose ESSID broadcast is disabled
2. fails to associate using WPA with AP whose ESSID broadcast is disabled
  a. if I manually set the ESSID, I get associated pretty quickly thereafter
3. associates using WPA to AP whose ESSID is broadcast without issues

I am attaching a debug level output of wpa_supplicant that shows the initial
stages of symptom 2, then you see the association occur just after I manually
specify the ESSID with 'iwconfig wlan0 essid Enterprise41'.

More information available on request.

Comment 18 Josh Miller 2007-09-06 20:10:02 UTC
Created attachment 189201 [details]
Log of failed association to WPA hidden AP, with subsequent association after manually specifying the ESSID

Comment 19 John W. Linville 2007-09-10 17:40:26 UTC
Joshua, please try again with the latest available fc7 kernel.  There has been 
a patch in place for a little while that helps w/ finding hidden essid 
networks.

Comment 20 Deependra Singh Shekhawat 2007-11-11 03:29:32 UTC
Hi,

I would like to re-open this bug for fedora 8. And it seems to be occuring only
with my Belkin Wireless Router. I tested things with Huwaei Wireless Router and
there seems to be no problem.
I am using these versions:
kernel-2.6.23.1-49.fc8

Once again what exactly I did was:
1) Disable NetworkManager and NetworkManagerDispatcher and the nm-applet.
2) killall dhclient
3) ifconfig wlan0 up
4) iwconfig wlan0 key 'key'
5) iwconfig wlan0 essid BSNL
6) dhclient wlan0

This made my laptop get associated with my Wireless Router but the last command
couldn't get the dhcp provided ip address.

Output was:
[root@localhost ~]# dhclient wlan0
Internet Systems Consortium DHCP Client V3.0.6-Fedora
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
wmaster0: unknown hardware address type 801
wmaster0: unknown hardware address type 801
Listening on LPF/wlan0/00:13:02:4b:70:05
Sending on   LPF/wlan0/00:13:02:4b:70:05
Sending on   Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5
No DHCPOFFERS received.
No working leases in persistent database - sleeping.


Comment 21 John W. Linville 2007-11-26 20:14:52 UTC
AP denied association (code=18)

Are you getting lines like this in /var/log/messages?

Comment 22 John W. Linville 2007-11-27 18:44:45 UTC
Please try these (or later) F7 kernels:

   http://koji.fedoraproject.org/koji/buildinfo?buildID=25270

Do these resolve the issue for you?

Comment 23 Christopher Brown 2008-01-09 14:18:17 UTC
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the kernel as John indicated these may
resolve the issue for you?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Comment 24 John W. Linville 2008-02-13 20:29:43 UTC
Close due to lack of response...