Red Hat Bugzilla – Bug 431894
iwl4965 unreliable connecting to LEAP
Last modified: 2009-06-19 22:18:07 EDT
Description of problem:
trying to connect to LEAP at IBM using a intel 4965 wireless card. Has issues
Version-Release number of selected component (if applicable):
el5.1 & test 2.6.18-77.el5 kernel.
In our lab we have set up a test network. 3 laptops. All within inches of each
Laptop A : t61 & 4965
Laptop B : t60 & madwifi
Laptop C : t43 & ipw200
Laptop B & Laptop C connect within seconds to the LEAP AP.
I have included logs file/configs, attached to this bug report.
In all cases "wpa_supplicant -Dwext -iwlan0 -cleap.conf -ddd" was used to get
this data, with the exception of madwifi where "wpa_supplicant -Dmadwifi -iwlan0
-cleap.conf -ddd" was used.
The reason I supply the additional data is so a comparison can be drawn.
Created attachment 294236 [details]
Laptop C : IPW2200 - Connecting to LEAP
Created attachment 294237 [details]
Laptop B : Madwifi connecting to LEAP
Created attachment 294238 [details]
Laptop A : iwl4965 struggling at connecting to LEAP
I should also mention, on a rare occasion the 4965 it does connect. But few and
Can you try to play around with the fragement_size network block option and see
if that makes a difference in the results? Try fragment_size=1300 and work down
I tried 1300 to 1000 in counts of -10, then 1000-0 in counts of -100.
Make little if any difference.
Created attachment 294356 [details]
Example of iwl4965 finally authenticating on LEAP
Perhaps this is also useful, after about 10 attempts, in this example it
finally authenticates with LEAP. This can take anywhere between 30 seconds and
The above bughost bug report suggests that the new iwl4965 driver version
snapshot02202008 (kernel-2.6.25rc2 with iwlwifi-1.2.26 built in) might improve
EAP-TLS (which we also use extensively). Can Red Hat consider backporting these
recent patches to RHEL 5.2?
There is no specific patch identified as fixing that issue. Unless such a
patch can be pinpointed, I don't think anything can be done until 5.3. Even
if there was such a patch, it would probably have to be a z-stream fix.
Can you recreate this issue with the rhel5 test kernels here?
Created attachment 306772 [details]
T61 iwl4965 working failed
Using 2.6.18-93.el5.jwltest.54 iwl4965 kernel.
Created attachment 308289 [details]
Compat Wireless 2008 06 03 Leap connection iwl4965 fc9
Does comment 13 represent success? Does the current fc9 kernel work as well?
Or does it require the compat-wireless bits?
I'm not going to commit taking drivers from an unreleased upstream kernel into
rhel5 at this time. I would much prefer to figure-out what patch actually fixed
the issue in question.
Issue is fixed now on fc9.
See update to https://bugzilla.redhat.com/show_bug.cgi?id=438813
Does this mean it will be fixed for 5.2 at some point?
Interesting enough in the latest F9 kernel its broken again
-kernel-184.108.40.206-86.fc9.i686.rpm. Leap will almost connect, I wonder if this
On F9 kernel-220.127.116.11-97.fc9.i686.rpm LEAP works again.
are there plans for el5.3 to add 2.6.26 driver updates to be added?
Test kernels w/ drivers from 2.6.26 available here:
Please give them a try and post the results here...thanks!
John, sorry for the delay, the new drivers seem to allow us to connect to LEAP, however when a dhclient request is made, the drivers lock up and cause a kernel panic. If I try connecting here at home using wpa-psk, works fine.
We are using the latest firmware. I can try and get you more information, if you can give me an idea what is useful.
Hmmm...well I need to see whatever messages the kernel outputs from the crash -- netconsole might be helpful for you to capture that.
Ping? What is the latest kernel you have tried?
we are still seeing kernel panics on some machines which have the iwl4965, I myself since the later kernels 118-121 no longer see the issue.
On a plus note we have been able to connect to LEAP using the iwl4965.
I will try and get my colleague to capture output using netconsole.
a colleague of mine managed to get the following on his T61p, trying to connect using 2.6.18-122.el5 x86_64 kernel from el 5.3 snap 2.
Nov 17 21:05:07 strongbad.local hsfserial(U)
Nov 17 21:05:32 strongbad.local Unable to handle kernel paging request
Nov 17 21:05:32 strongbad.local at fffffffffffffea4 RIP:
Nov 17 21:05:32 strongbad.local [<ffffffff882640c5>] :mac80211:ieee80211_get_tkip_key+0x5a/0xe9
Nov 17 21:05:32 strongbad.local PGD 203067
Nov 17 21:05:32 strongbad.local PUD 2371067
Nov 17 21:05:32 strongbad.local PMD 0
Nov 17 21:05:32 strongbad.local
Nov 17 21:05:32 strongbad.local Oops: 0000 
Nov 17 21:05:32 strongbad.local SMP
Nov 17 21:05:32 strongbad.local
Nov 17 21:05:32 strongbad.local last sysfs file: /class/net/eth0/broadcast
Nov 17 21:05:32 strongbad.local CPU 0
Nov 17 21:05:32 strongbad.local
Nov 17 21:05:32 strongbad.local Modules linked in:
Nov 17 21:05:32 strongbad.local netconsole
Nov 17 21:05:32 strongbad.local lt_hotswap(U)
Nov 17 21:05:32 strongbad.local tun
Nov 17 21:05:32 strongbad.local bridge
Nov 17 21:05:32 strongbad.local bnep
Nov 17 21:05:32 strongbad.local rfcomm
Nov 17 21:05:32 strongbad.local l2cap
Nov 17 21:05:33 strongbad.local autofs4
Nov 17 21:05:33 strongbad.local vmnet(U)
Nov 17 21:05:33 strongbad.local vsock(FU)
Nov 17 21:05:33 strongbad.local vmci(U)
Nov 17 21:05:33 strongbad.local vmmon(U)
Nov 17 21:05:33 strongbad.local ip_conntrack_irc
Nov 17 21:05:33 strongbad.local ip_conntrack_ftp
Nov 17 21:05:33 strongbad.local iptable_nat
Nov 17 21:05:33 strongbad.local ip_nat
Nov 17 21:05:33 strongbad.local ipt_LOG
Nov 17 21:05:33 strongbad.local xt_limit
Nov 17 21:05:33 strongbad.local ipt_REJECT
Nov 17 21:05:33 strongbad.local xt_tcpudp
Nov 17 21:05:33 strongbad.local xt_state
Nov 17 21:05:33 strongbad.local ip_conntrack
Nov 17 21:05:33 strongbad.local nfnetlink
Nov 17 21:05:33 strongbad.local iptable_filter
Nov 17 21:05:33 strongbad.local ip_tables
Nov 17 21:05:33 strongbad.local x_tables
Nov 17 21:05:33 strongbad.local cpufreq_ondemand
Nov 17 21:05:33 strongbad.local acpi_cpufreq
Nov 17 21:05:33 strongbad.local freq_table
Nov 17 21:05:33 strongbad.local dm_mirror
Nov 17 21:05:33 strongbad.local dm_log
Nov 17 21:05:33 strongbad.local dm_multipath
Nov 17 21:05:33 strongbad.local scsi_dh
Nov 17 21:05:33 strongbad.local dm_mod
Nov 17 21:05:33 strongbad.local video
Nov 17 21:05:33 strongbad.local sbs
Nov 17 21:05:33 strongbad.local i2c_ec
Nov 17 21:05:33 strongbad.local button
Nov 17 21:05:33 strongbad.local battery
Nov 17 21:05:33 strongbad.local asus_acpi
Nov 17 21:05:33 strongbad.local acpi_memhotplug
Nov 17 21:05:33 strongbad.local ac
Nov 17 21:05:33 strongbad.local parport_pc
Nov 17 21:05:33 strongbad.local lp
Nov 17 21:05:33 strongbad.local parport
Nov 17 21:05:34 strongbad.local thinkpad_acpi
Nov 17 21:05:34 strongbad.local hwmon
How often does this occur? Is there a way to reliably recreate it?
From what I understand, it seems like a TKIP issue, not appearing connecting using AES. i.e. WPA Crashes, WPA2 does not.
It's just that it looks a bit like a TKIP bug that is supposed to already be fixed in -122.el5. Are you sure that is the kernel being run?
Checking John, I understood from colleagues they were on -122.el5. However looks like they were still on -121.el5. Have asked them to updated and retest
looks like the crashes were indeed resolved with the -122.el5 kernel.