Bug 203421 - Grabbing DHCP address via wireless not always successful
Grabbing DHCP address via wireless not always successful
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.4
i386 Linux
high Severity high
: ---
: ---
Assigned To: John W. Linville
Jay Turner
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-21 16:02 EDT by Meethune Bhowmick
Modified: 2015-01-07 19:14 EST (History)
8 users (show)

See Also:
Fixed In Version: RHSA-2006-0689
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-05 15:18:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
0001-ipw2200-remove-the-WPA-card-associates-to-non-WPA-AP-checking.txt (1.39 KB, patch)
2006-08-24 10:51 EDT, John W. Linville
no flags Details | Diff
0002-ipw2200-Fix-wpa_supplicant-association-problem.txt (1.22 KB, patch)
2006-08-24 10:54 EDT, John W. Linville
no flags Details | Diff
Sysreport run shortly after reboot (261.46 KB, application/x-bzip2)
2006-09-06 12:45 EDT, Meethune Bhowmick
no flags Details
Sysreport after failed association and dhclient attempt (263.17 KB, application/x-bzip2)
2006-09-06 12:47 EDT, Meethune Bhowmick
no flags Details
dmesg output when connected to rh-wireless w/ version .5 kernel (17.18 KB, application/octet-stream)
2006-09-13 10:45 EDT, Bob Johnson
no flags Details
Dmesg of .5 kernel after intial boot, before dhclient (123.61 KB, text/plain)
2006-09-13 11:49 EDT, Meethune Bhowmick
no flags Details
Dmesg of .5 kernel after failed dhclient attempt (123.61 KB, text/plain)
2006-09-13 11:50 EDT, Meethune Bhowmick
no flags Details
dmesg of failed connection at home to DLink router (123.36 KB, text/plain)
2006-09-13 18:28 EDT, Bob Johnson
no flags Details
wireless-stats.patch (2.28 KB, patch)
2006-09-14 16:39 EDT, John W. Linville
no flags Details | Diff
dmesg of failed connection at home to DLink router with .6 kernel (122.10 KB, text/plain)
2006-09-15 13:01 EDT, Bob Johnson
no flags Details
ipw2200-dhcp-fix.patch (4.00 KB, patch)
2006-09-16 07:41 EDT, John W. Linville
no flags Details | Diff
.7 kernel works !!! :)....dmesg output attached as proof... (123.43 KB, text/plain)
2006-09-17 21:10 EDT, Bob Johnson
no flags Details

  None (edit)
Description Meethune Bhowmick 2006-08-21 16:02:42 EDT
Hi, I work internal helpdesk @ Redhat. We are having some issues regarding
wireless. I will updated this bug with any additional information required.

Description of problem:
Not always, but for some APs, One can associate to it but never receive dhcp
offer from server. Connecting to the Red Hat internal wireless (rh-wireless)
works just fine. However connecting to other APs (from our tickets, mostly home
wireless routers) never returns an IP from dhcp. This is for both for encrypted
and non-encrypted APs. The issue popped up when some of our users upgraded to
RHEL4 U4. I have verified this by testing with U3 (which works perfect) and then
upgrading to U4 and testing again (fails).

Version-Release number of selected component (if applicable):
wireless-tools-28.0.pre16.3.3.EL4

How reproducible:
Dependent on AP

Steps to Reproduce:
1. iwconfig eth1 essid "An Access Point"
2. dhclient eth1
  
Actual results:
Copyright 2004 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP

Listening on LPF/eth1/00:13:ce:79:2f:5e
Sending on   LPF/eth1/00:13:ce:79:2f:5e
Sending on   Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 18
No DHCPOFFERS received.
No working leases in persistent database - sleeping.


Expected results:
Internet Systems Consortium DHCP Client V3.0.1
Copyright 2004 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP

Listening on LPF/eth1/00:13:ce:79:2f:5e
Sending on   LPF/eth1/00:13:ce:79:2f:5e
Sending on   Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5
DHCPOFFER from 172.16.52.28
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPACK from 172.16.52.28
bound to 172.16.55.222 -- renewal in 8689 seconds.


Additional info:
I get this as well from ipw2200 module:
ipw2200: Unknown notification: subtype=40,flags=0xa0,size=40

These related installed packages:
kernel-2.6.9-41.EL
dhclient-3.0.1-58.EL4
ipw2200-firmware-2.4-1
Comment 2 Dan Williams 2006-08-22 16:41:18 EDT
Meethune, a few things to try to troubleshoot:

1) downgrade just the wireless-tools RPM to the RHEL4 U3 version, and see if the
problem persists

2) reinstall the U4 wireless-tools, but downgrade the _kernel_ to the U3 version

This may actually be an ipw2x00 kernel driver issue, not wireless tools.  The
ipw2x00 drivers and the in-kernel 802.11 stack received updates to support WPA
as well.  We need to isolate the issue to either the kernel or wireless-tools.
Comment 3 Meethune Bhowmick 2006-08-22 17:51:10 EDT
(In reply to comment #2)
1. Downgrading wireless-tools to 24-0.pre25.4.EL4 with 2.6.9-42 kernel fails

2. Downgrading Kernel to 2.6.9-34.0.2.EL with wireless-tools-28-0.pre16.3.3.EL4
allowed me to receive a dhcp address.

A new kernel was released (2.6.9-42.0.2) today. I tried that as well with the U4
wireless tools to no avail. 

Cheers,
Meethune

Comment 4 Dan Williams 2006-08-23 00:12:30 EDT
Ok; sounds more like a kernel problem, adding John Linville.

John, any ideas?  Seems to be isolated to only people with ipw2x00 cards.  When
testing the kernel update, I did get the Unknown notification messages, but when
I looked into them they appeared to be harmless.
Comment 5 Dan Williams 2006-08-23 00:13:54 EDT
(In reply to comment #1)
> Chris, I am seeing this on my laptop which I updated to RHEL 4.4 and Jake
> Walters downloaded wireless-tools-28.0.pre16.3.3.EL4.  I am able to wifi at work
> but not at home.  100% of the time at home, I cannot get an IP address.  I am
> willing to test patches for you as I'd really like this resolved ASAP.  I think
> we need an async errata for this issue.

Suzanne, what make & model is your home access point?  Are you using any type of
encryption, and if so, what kind?  WEP? WPA1/TKIP? WPA1/CCMP/AES?  WPA2/TKIP? 
or WPA2/CCMP/AES?
Comment 6 Bob Johnson 2006-08-23 10:02:49 EDT
My home setup which is where this issue started.
Dlink 802.11b router, 128bit wep, essid is not broadcast, mac filtered.
works fine on U3 as I have gone back to that version of kernel.
so was it kernel changes ? wifi radar ? wireless tools ?

some additional data I can collect here ?
Comment 7 John W. Linville 2006-08-23 10:10:55 EDT
Is it it realy both ipw2100 and ipw2200 (and ipw2915)?  Or is it really just 
one of those?

If you configure a static IP address, does the box work?
Comment 8 Meethune Bhowmick 2006-08-23 10:34:04 EDT
(In reply to comment #7)
> Is it it realy both ipw2100 and ipw2200 (and ipw2915)?  Or is it really just 
> one of those?
> 
> If you configure a static IP address, does the box work?

I've only tested w/ ipw2200. With a static IP, I cannot ping the gateway.

Meethune
Comment 9 John W. Linville 2006-08-23 13:31:23 EDT
Could you try my test kernels?

   http://people.redhat.com/linville/kernels/rhel4/

These include further updates to the ieee80211 code and the ipw2100 and 
ipw2200 drivers, as well as including the ipw3945 driver.  Do these kernels 
behave any differently?
Comment 10 Meethune Bhowmick 2006-08-23 14:09:17 EDT
(In reply to comment #9)
I installed your test kernel and new firmware. It seems we have success. I was
able to get a dhcp address from wireless. However it did take a few DHCPOFFERS
before it finally took the address. Here is an abreviated output of dhclient.

Listening on LPF/eth1/00:13:ce:79:2f:5e
Sending on   LPF/eth1/00:13:ce:79:2f:5e
Sending on   Socket/fallback
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 13
DHCPOFFER from 192.168.0.1
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
DHCPOFFER from 192.168.0.1
<does this a couple more time>
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.105 -- renewal in 284112 seconds.
Comment 11 Suzanne Yeghiayan 2006-08-23 17:19:26 EDT
Replying to comment 5:
I have a Linksys router at home that does not have WEP enabled.
I can send make and model later tonight.
I am able to vpn when wired directly to the router.
Can't vpn wifi.
John, should I try your test kernel?
Comment 12 Suzanne Yeghiayan 2006-08-23 18:41:13 EDT
John, I tried vmlinuz-2.6.9-42.2.EL.jwltest.160 and when I ran wifi-radar, my
system was not able to get an IP address.  I have rebooted with 2.6.9-42.

I know when I asked helpdesk for assistance, they needed to rebuild the
wireless-tools package to match the kernel.  Is this step needed?
Comment 13 Bob Johnson 2006-08-23 18:48:10 EDT
I also tried...kernel-2.6.9-42.2.EL.jwltest.160.i686.rpm
Association fails, and therefoe no IP, which is a bit worse than stock 4.4, and
also I see no access points at all, reboot to 4.4 (-42) and see multiple APs,
but can not get any IP.
Comment 14 Meethune Bhowmick 2006-08-23 19:01:52 EDT
If you use the testing kernel and have an ipw2200, make sure to get the updated
firmware for your card from 

http://ipw2200.sourceforge.net/firmware.php?fid=7

remove the old firmware with a rpm -e ipw2200-firmware. Extract the firmware
tarball and copu the *.fw files into /lib/firmware .

I've tested with kernel-2.6.9-42.2.EL.jwltest.158, ipw2200-fw-3.0, and
wifi-radar works just fine.

Meethune Bhowmick
Desktop Systems Specialist, RHCE
Global Help Desk, Centennial Office
+1 919-754-3700 x44542

GnuPG Fingerprint:
BF72 E81C B35E C117 2207  2A51 688A 48F1 7042 BC04

Visit the Help Desk Portal @ http://helpdesk.redhat.com
for answers to common questions and other neat information
Comment 15 Bob Johnson 2006-08-23 22:10:58 EDT
ok deleted old fw, added new fw - works like a champ to the DLink AP here at home.

so we get to see this fix in February 2007 ?
Comment 16 Suzanne Yeghiayan 2006-08-24 08:43:32 EDT
More info on my home wireless router: It's a Linksys G, model WRT54G.  
Comment 17 Suzanne Yeghiayan 2006-08-24 08:46:53 EDT
I've got ipw2200-firmware-2.4-1 on my laptop.  Should I also update this package?
Comment 18 Bob Johnson 2006-08-24 08:55:29 EDT
Sly, just follow Meethune's instructions from comment #14 above, so basically yes.
We have two data points that say this kernel change fixes this issue, so not
sure we need a 3rd ?  If you rpm -e that package you can get it back from RHN later.
Comment 19 Dan Williams 2006-08-24 09:16:28 EDT
I'd like to test this kernel update with WPA before we call it a go... since
that was the original reason the drivers were updated, we should make sure that
works.
Comment 20 Bob Johnson 2006-08-24 09:29:09 EDT
I would agree, I've only tested the regression case.
Comment 21 John W. Linville 2006-08-24 10:51:57 EDT
Created attachment 134820 [details]
0001-ipw2200-remove-the-WPA-card-associates-to-non-WPA-AP-checking.txt
Comment 22 John W. Linville 2006-08-24 10:54:07 EDT
Created attachment 134821 [details]
0002-ipw2200-Fix-wpa_supplicant-association-problem.txt
Comment 23 John W. Linville 2006-08-24 10:59:17 EDT
My bet is that one or both (probably just the first one) of those two patches 
is sufficient to relieve the problem in U4.

Anyone that can recreate the issue competent (and confident) to apply the 
patch to U4 kernel sources, build that kernel, and test?  If not, can I have a 
volunteer to take a one-off kernel from beehive?  (I'm trying to avoid 
patch "flap" in my normal test kernels, while narrowing down the exact fix 
possibly for the E4 stream.)

So, volunteers?
Comment 24 John W. Linville 2006-08-24 11:04:58 EDT
Hmmm...FWIW, I guess that would be E5?  Whatever, you know what I meant... :-)
Comment 25 Meethune Bhowmick 2006-08-24 11:31:35 EDT
(In reply to comment #23)
> My bet is that one or both (probably just the first one) of those two patches 
> is sufficient to relieve the problem in U4.
> 
> Anyone that can recreate the issue competent (and confident) to apply the 
> patch to U4 kernel sources, build that kernel, and test?  If not, can I have a 
> volunteer to take a one-off kernel from beehive?  (I'm trying to avoid 
> patch "flap" in my normal test kernels, while narrowing down the exact fix 
> possibly for the E4 stream.)
> 
> So, volunteers?

I can test this. I'll report back my results.

Meethune
Comment 26 Bob Johnson 2006-08-24 12:49:52 EDT
John L - you build it I'll test it.
Comment 27 Meethune Bhowmick 2006-08-24 13:30:39 EDT
(In reply to comment #25)
Should clarify. I'm building the kernel right now.

Meethune

Comment 29 Meethune Bhowmick 2006-08-24 15:55:51 EDT
OK, I've built the kernels, but it seems that the issue isn't resolved. I get
the same issue as with the stock U4 kernel. 

I don't have publicly available hosting, so I'll post an internal link, and
whoever can rehost it if you wish.

http://kickstart.rdu.redhat.com/data/linux/helpdesk/bug_20341_kernel/

Make sure if you were using John's testing kernel that you delete
/lib/firmware/ipw2200* and up2date ipw2200-firmware so that you have the correct
firmware for this build.

Meethune
Comment 30 Bob Johnson 2006-08-24 19:04:33 EDT
I agree with Meethune - this latest kernel is similar to the stock u4 kernel.
I can not get an IP, but I can see other APs, that the stock U4 kernel does not
see.  I in fact have deleted the new fw and went back to the u4 stock ipw fw. 
This test kernel did in fact work with the rh-wireless AP at centennial
when I ran it there.
Comment 31 Bob Johnson 2006-08-25 10:51:12 EDT
next kernel to test ?
Comment 33 Bob Johnson 2006-08-26 09:49:18 EDT
thumbs down on the .1 kernel with my Dlink.
works for rh-wireless, not at home.
Could not get IP, same results as my comment #30.
Comment 35 Meethune Bhowmick 2006-08-28 15:44:49 EDT
John,
  I've tested 2.6.9-42.EL.linville.bz203421.2 with the ipw2200-3.0 firmware. I
get no love. It behaves in the same fashion as the stock 42 and 42.0.2 kernels.
It sends out DHCPDISCOVER but never receives anything back. I don't see anything
useful in dmesg that would provide any clues. I also tried setting it to static
IP and I cannot ping the gateway.

Meethune
Comment 36 Bob Johnson 2006-08-28 16:32:56 EDT
based upon comment #35 I don't plan to test .2 at home tonight ....:)
Comment 44 Meethune Bhowmick 2006-09-05 16:16:12 EDT
John,
  Same result as before with your new kernel. I copy paste a screenlog so you
can see exactly what I see and do.

Meethune

[root@bhowmick ~]# iwconfig eth1 essid "NCSU-SSL"
[root@bhowmick ~]# dhclient eth1
Internet Systems Consortium DHCP Client V3.0.1
Copyright 2004 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP

/sbin/dhclient-script: configuration for eth1 not found. Continuing with defaults.
/etc/sysconfig/network-scripts/network-functions: line 52: eth1: No such file or
directory
Listening on LPF/eth1/00:16:6f:92:05:62
Sending on   LPF/eth1/00:16:6f:92:05:62
Sending on   Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 10
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
/sbin/dhclient-script: configuration for eth1 not found. Continuing with defaults.
/etc/sysconfig/network-scripts/network-functions: line 52: eth1: No such file or
directory
[root@bhowmick ~]#
[root@bhowmick ~]# uname -a
Linux bhowmick.csb 2.6.9-42.EL.linville.bz203421.4 #1 Tue Sep 5 13:31:41 EDT
2006 i686 i686 i386 GNU/Linux
ipw2200: Unknown notification: subtype=40,flags=0xa0,size=40
[root@bhowmick ~]# exit
Comment 46 John W. Linville 2006-09-06 11:32:42 EDT
Well, that stinks...it may be difficult to isolate a precise fix for this 
issue.  If so, we may have to wait for 4.5...

Can you attach the output of running 'sysreport' on one (or more) of these 
boxes, shortly after a reboot (and after a failed association attempt)?  
Thanks!
Comment 47 Meethune Bhowmick 2006-09-06 12:45:15 EDT
Created attachment 135669 [details]
Sysreport run shortly after reboot
Comment 48 Meethune Bhowmick 2006-09-06 12:47:07 EDT
Created attachment 135670 [details]
Sysreport after failed association and dhclient attempt
Comment 49 Meethune Bhowmick 2006-09-06 12:48:44 EDT
John,
  I've posted two sysreports, One right after boot, and one after the failed
association.

Cheers,
Meethune
Comment 50 John W. Linville 2006-09-08 13:49:23 EDT
The associate issue tracker suggests that booting w/ the U3 kernel (and 
bringing-up wireless?), then re-booting w/ the U4 kernel allows things to work 
w/ the U4 kernel.  Can anyone confirm this?
Comment 51 Bob Johnson 2006-09-11 21:14:56 EDT
I tested this. U3 gets IP, able to vpnc on top of that back to rhat.
reboot with U4 - unable to get IP, my conclusion - comment in IT not reproducable.
Comment 52 Bob Johnson 2006-09-13 10:45:20 EDT
Created attachment 136159 [details]
dmesg output when connected to rh-wireless w/ version .5 kernel

kernel.5 output from successful conenction to redhat-wireless
Comment 53 John W. Linville 2006-09-13 11:10:28 EDT
As Bob's note indicates, a new test kernel (.5) is available.  It is basically 
just the U4 kernel w/ some extra debugging turned-on.

Please give that kernel a try.  You will also need to execute the following 
before trying to associate:

   echo 0xffffffff > /sys/bus/pci/drivers/ipw2200/debug_level

Afterwards, please attach the output of running dmesg...thanks!
Comment 54 Meethune Bhowmick 2006-09-13 11:49:10 EDT
Created attachment 136174 [details]
Dmesg of .5 kernel after intial boot, before dhclient
Comment 55 Meethune Bhowmick 2006-09-13 11:50:51 EDT
Created attachment 136175 [details]
Dmesg of .5 kernel after failed dhclient attempt
Comment 56 Meethune Bhowmick 2006-09-13 11:53:13 EDT
John,
  I've attached two dmesg outputs, one after the initial boot and one that is
after a failed dhclient attempt.

Cheers,
Meethune
Comment 57 Bob Johnson 2006-09-13 18:28:53 EDT
Created attachment 136218 [details]
dmesg of failed connection at home to DLink router
Comment 58 John W. Linville 2006-09-13 19:03:38 EDT
FWIW, I'm posting this comment using a T42 Thinkpad w/ IPW2915 (uses ipw2200
driver) from my living room.  For the record, I use WRT54G access points with
the OpenWRT replacement firmware.
Comment 59 John W. Linville 2006-09-13 19:05:56 EDT
I should have added in comment 58 that I am using RHEL4 U4 with the stock U4 kernel:

[linville@localhost ~]$ uname -a
Linux localhost.localdomain 2.6.9-42.EL #1 Wed Jul 12 23:16:43 EDT 2006 i686
i686 i386 GNU/Linux
Comment 61 John W. Linville 2006-09-14 11:14:01 EDT
FWIW, commnet 58 and comment 59 are equally true when I use actual IPW2200 
hardware (i.e. not IPW2915).

How are you configuring your network?  I know Bob J. is using wifi-radar.  Is 
the same true for everyone?

Do you get the same results using system-config-network (after stopping 
wifi-radar, NetworkManager, or whatever)?
Comment 62 Meethune Bhowmick 2006-09-14 11:40:13 EDT
(In reply to comment #61)
All wifi-radar does is run iwconfig, iwlist + dhclient and scrapes the output. I
have been using plain cli tools in my tests. 
At RDU we run cisco APs + WEP for rh-wireless. We have no issues connecting to
those. The problem that we are having, is our users try to connect to their home
APs, they do not receive an address. This is either via dhcp or static IP. This
leads me to believe that the association to the AP is not happening.

I tried using system-config-network and tried to connect to the local university
AP. It is not using encryption at all. The results are the same as when I ran
plain cli tools (works w/ U3 kernel, not U4 kernel). I ran iwevent while trying
to connect to the university wireless and the rh-wireless. Let me know if there
is any more info you need or if I need to clarify anything.

Linux bhowmick.csb 2.6.9-42.EL.linville.bz203421.5 #1 Tue Sep 12 15:47:06 EDT
2006 i686 i686 i386 GNU/Linux

(Failed)
[root@bhowmick ~]# iwevent
Waiting for Wireless Events from interfaces...
11:25:22.691814   eth1     Set Mode:Managed
11:25:22.714044   eth1     Set Encryption key:off
11:25:22.732140   eth1     Set ESSID:"NCSU-SSL"

(Successful)
[root@bhowmick ~]# iwevent
Waiting for Wireless Events from interfaces...
11:32:10.292068   eth1     Set Mode:Managed
11:32:10.381276   eth1     Set Encryption key:****-****-****-****-****-****-**
11:32:10.385582   eth1     Set ESSID:"rh-wireless"
11:32:10.391908   eth1     New Access Point/Cell address:Not-Associated
11:32:10.677976   eth1     New Access Point/Cell address:00:13:19:E3:4C:80
Comment 63 John W. Linville 2006-09-14 16:39:37 EDT
Created attachment 136301 [details]
wireless-stats.patch
Comment 64 John W. Linville 2006-09-14 16:48:33 EDT
".6" kernels are now available.  They include the above patch, which merely 
puts-back the "get_wireless_stats" stuff in the ipw2[12]00 drivers.  I dunno 
if this will help or not, but NM seemed to like it better on my U4 + debug + 
above patch kernel.

It is possible that something is getting confused w/o the proper entry 
in /proc/net/wireless (which is what get_wireless_stats is for).
Comment 65 John W. Linville 2006-09-14 16:51:53 EDT
I guess I should add "please give the .6 kernels a try and post the 
results" -- thanks! :-)
Comment 66 John W. Linville 2006-09-14 17:26:36 EDT
BTW, just curious -- are any of the failing boxes "fresh" U4 installs?  Or were
they all updated from U3?

Also, what versions of the wireless-tools package is everyone using?

   rpm -qa | grep wireless-tools
Comment 67 John W. Linville 2006-09-14 17:28:38 EDT
For the record, I'm using wireless-tools-28-0.pre16.3.3.EL4.
Comment 68 Meethune Bhowmick 2006-09-14 17:32:10 EDT
(In reply to comment #66)
> BTW, just curious -- are any of the failing boxes "fresh" U4 installs?  Or were
> they all updated from U3?
> 
> Also, what versions of the wireless-tools package is everyone using?
> 
>    rpm -qa | grep wireless-tools

My first few tests when the bug was first opened had been from upgraded
machines. Subsequently, the last group of tests have been performed from Freshly
installed U4 machines.

I'm running wireless-tools-28-0.pre16.3.3.EL4
Comment 69 Meethune Bhowmick 2006-09-14 17:41:12 EDT
Just tested new .6 kernel, it seems like it associates with my problem AP
temporarily. It also looks like the version of wireless tools this kernel was
compiled against was different than before? As always, let me know if you need
more info.

Warning : Device eth1 has been compiled with version 18
of Wireless Extension, while we are using version 16.
Some things may be broken...

This still works...
[root@bhowmick ~]# iwevent
Waiting for Wireless Events from interfaces...
17:30:55.303888   eth1     Set Mode:Managed
17:30:55.394472   eth1     Set Encryption key:****-****-****-****-****-****-**
17:30:55.394799   eth1     New Access Point/Cell address:Not-Associated
17:30:55.397366   eth1     Set ESSID:"rh-wireless"
17:30:55.664691   eth1     New Access Point/Cell address:00:13:19:E3:4C:80

This still fails, but at least it sees the AP this time
[root@bhowmick ~]# iwevent
Waiting for Wireless Events from interfaces...
17:31:25.779587   eth1     Set Mode:Managed
17:31:25.788050   eth1     Set Encryption key:off
17:31:25.796540   eth1     Set ESSID:"NCSU-SSL"
17:31:25.796580   eth1     New Access Point/Cell address:Not-Associated
17:31:26.442524   eth1     New Access Point/Cell address:00:40:05:CB:61:38
17:31:33.207643   eth1     New Access Point/Cell address:Not-Associated
17:31:33.518173   eth1     New Access Point/Cell address:Not-Associated
17:31:36.775162   eth1     New Access Point/Cell address:Not-Associated
17:31:40.038901   eth1     New Access Point/Cell address:Not-Associated
17:31:43.301139   eth1     New Access Point/Cell address:Not-Associated
17:31:46.538651   eth1     New Access Point/Cell address:00:40:05:CB:61:38
17:31:50.614127   eth1     New Access Point/Cell address:Not-Associated
17:31:50.906244   eth1     New Access Point/Cell address:00:40:05:CB:61:38
17:31:56.348806   eth1     New Access Point/Cell address:Not-Associated
17:31:56.660492   eth1     New Access Point/Cell address:00:40:05:CB:61:38
17:32:05.567589   eth1     New Access Point/Cell address:Not-Associated
17:32:05.855279   eth1     New Access Point/Cell address:00:40:05:CB:61:38
17:32:23.589508   eth1     New Access Point/Cell address:Not-Associated
17:32:23.973433   eth1     New Access Point/Cell address:00:40:05:CB:61:38
Comment 70 Bob Johnson 2006-09-15 12:59:58 EDT
no work with the dlink, dmesg to attach
Comment 71 Bob Johnson 2006-09-15 13:02:00 EDT
Created attachment 136377 [details]
dmesg of failed connection at home to DLink router with .6 kernel
Comment 72 John W. Linville 2006-09-16 07:41:09 EDT
Created attachment 136420 [details]
ipw2200-dhcp-fix.patch
Comment 73 John W. Linville 2006-09-16 07:45:05 EDT
OK...I have .7 kernels available.  After replicating Meethune's scenario w/ the
.6 kernel, the patch from comment 72 solved it for me.

Please give .7 a try ASAP to verify that the issue is solved in the other
scenarios.  I'm fairly confident that it will be.
Comment 74 John W. Linville 2006-09-16 08:13:24 EDT
"Warning : Device eth1 has been compiled with version 18
of Wireless Extension, while we are using version 16.
Some things may be broken..."

Meethune, could you also add comments to bug 189987 indicating the version of
wireless-tools you have and which commands are generating those wireless
extension messages?  Thanks!
Comment 75 Meethune Bhowmick 2006-09-16 18:48:28 EDT
(In reply to comment #74)
> Meethune, could you also add comments to bug 189987 indicating the version of
> wireless-tools you have and which commands are generating those wireless
> extension messages?  Thanks!

I tried to comment to that bug but I get an access denied. In any case, the
situation occurs when running system-config-network with
wireless-tools-28-0.pre16.3.3.EL4 .

My home accesspoint (WRT54g + OpenWRT) works just fine. I'll test the new kernel
with the problem NCSU AP first thing when I get in on Monday.

Comment 76 Bob Johnson 2006-09-17 21:10:12 EDT
Created attachment 136499 [details]
.7 kernel works !!! :)....dmesg output attached as proof...
Comment 77 Bob Johnson 2006-09-17 21:22:31 EDT
and to be specific - it works with my Dlink DL-514 wireless 802.11b router at home.
Comment 78 Dan Williams 2006-09-18 11:25:31 EDT
John, the version of wireless-tools that was pushed out with U4 shouldn't give
that message when using a kernel that has WEXT 18.  So it's likely that the
message is coming from a U3 system with old wireless-tools, or Bob installed the
U3 wireless-tools on the U4 system to ensure that it was not the cause of the
problem.

WRT the patch, great!
Comment 79 Dan Williams 2006-09-18 11:31:52 EDT
(In reply to comment #75)
> (In reply to comment #74)
> > Meethune, could you also add comments to bug 189987 indicating the version of
> > wireless-tools you have and which commands are generating those wireless
> > extension messages?  Thanks!
> 
> I tried to comment to that bug but I get an access denied. In any case, the
> situation occurs when running system-config-network with
> wireless-tools-28-0.pre16.3.3.EL4 .

Ok; that's a bit different as that version of wireless-tools is the correct
version for the U4 update.  This means that the tool that linked to
/usr/lib/libiw.so was compiled for an earlier version of the library. 
wireless-tools is patched to not display that message for versions N and N-1. 
Would be useful to see what tool is actually being run such that that message is
produced.  system-config-network is python, so likely it's calling some other
tool underneath that produces that message.
Comment 80 Bob Johnson 2006-09-18 12:26:32 EDT
in reference to comment #78 above, I've just been kernel and firmware swapping
per the info above, so to the best of my knowledge I'm running that stock U4
wireless tools.  I am using the helpdesk wi-fi radar for most connections, not
sure what that calls other than iwconfig.
Comment 81 Meethune Bhowmick 2006-09-18 13:41:06 EDT
Hrm, I still cannot connect to NCSU-SSL with the .7 kernel. John, what were the
exact steps you did to connect to the NCSU-SSL wireless. Since others are
reporting success, I think I may be doing something wrong. However when I run
system-config-network and try and connect and have iwevent running in a
terminal, iwevent is reporting that it isn't associated to NCSU-SSL.

Comment 82 John W. Linville 2006-09-18 13:46:11 EDT
No "extra" steps at all.  The NCSU-SSL signal was pretty weak in general, but 
I didn't do anything special.
Comment 85 Bob Johnson 2006-09-18 16:27:45 EDT
and 0.7 works against rh-wireless access points in Raleigh (which was never a
problem with the stock 4.4 kernel) 
Comment 90 Jason Baron 2006-09-19 15:41:33 EDT
committed in stream U5 build 42.12. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/
Comment 91 Meethune Bhowmick 2006-09-21 13:27:15 EDT
Yay! It works like it should. NCSU-SSL is just a very weak signal. Thanks alot
John for all your hard work. Tested it with the 42.12 test kernel.

Cheers,
Meethune
Comment 92 Jason Baron 2006-09-26 10:42:41 EDT
committed in stream E5 build 42.0.3
Comment 96 Red Hat Bugzilla 2006-10-05 15:19:00 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2006-0689.html

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