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.

(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

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.

(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?

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 ?

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?

(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

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?

(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.

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?

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?

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.

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

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 ?

More info on my home wireless router: It's a Linksys G, model WRT54G.  

I've got ipw2200-firmware-2.4-1 on my laptop.  Should I also update this package?

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.

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.

I would agree, I've only tested the regression case.

Created attachment 134820 [details]
0001-ipw2200-remove-the-WPA-card-associates-to-non-WPA-AP-checking.txt

Created attachment 134821 [details]
0002-ipw2200-Fix-wpa_supplicant-association-problem.txt

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?

Hmmm...FWIW, I guess that would be E5?  Whatever, you know what I meant... :-)

(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

John L - you build it I'll test it.

(In reply to comment #25)
Should clarify. I'm building the kernel right now.

Meethune

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

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.

next kernel to test ?

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.

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

based upon comment #35 I don't plan to test .2 at home tonight ....:)

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

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!

Created attachment 135669 [details]
Sysreport run shortly after reboot

Created attachment 135670 [details]
Sysreport after failed association and dhclient attempt

John,
  I've posted two sysreports, One right after boot, and one after the failed
association.

Cheers,
Meethune

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?

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.

Created attachment 136159 [details]
dmesg output when connected to rh-wireless w/ version .5 kernel

kernel.5 output from successful conenction to redhat-wireless

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!

Created attachment 136174 [details]
Dmesg of .5 kernel after intial boot, before dhclient

Created attachment 136175 [details]
Dmesg of .5 kernel after failed dhclient attempt

John,
  I've attached two dmesg outputs, one after the initial boot and one that is
after a failed dhclient attempt.

Cheers,
Meethune

Created attachment 136218 [details]
dmesg of failed connection at home to DLink router

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.

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

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)?

(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

Created attachment 136301 [details]
wireless-stats.patch

".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).

I guess I should add "please give the .6 kernels a try and post the 
results" -- thanks! :-)

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

For the record, I'm using wireless-tools-28-0.pre16.3.3.EL4.

(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

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

no work with the dlink, dmesg to attach

Created attachment 136377 [details]
dmesg of failed connection at home to DLink router with .6 kernel

Created attachment 136420 [details]
ipw2200-dhcp-fix.patch

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.

"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!

(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.

Created attachment 136499 [details]
.7 kernel works !!! :)....dmesg output attached as proof...

and to be specific - it works with my Dlink DL-514 wireless 802.11b router at home.

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!

(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.

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.

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.

No "extra" steps at all.  The NCSU-SSL signal was pretty weak in general, but 
I didn't do anything special.

and 0.7 works against rh-wireless access points in Raleigh (which was never a
problem with the stock 4.4 kernel) 

committed in stream U5 build 42.12. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/

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

committed in stream E5 build 42.0.3

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