We are having some issues with our machines obtaining DHCP leases when MIC is enabled. As soon as we turn off MIC everything works fine.
We have upgraded firmware on both the clients & WAPs, drivers and Utility without any luck.
That's exactly my problem. I worked the issue through TAC and they could not duplicate but they did send me a new AP which exhibited the same failure. Since I don't have a way to sniff the RF I"m not sure what's going on, right now, I have disabled MIC to allow DHCP to work. Since my AP's are located in a warm environment I wanted to see if a cooler ambient temp may improve the situation but this is just a hunch.
I have not yet involved TAC in my case. We have 3 - 350 WAPs and 3 - 340 WAPs and they all share the same failure. We have multiple cards also; PCMCIA 340 & 350's and mPCI 350's and its a handful of them that have the problem the rest seem to work without any noticeable issues.
We are running under normal temp conditions in our office. We have not run any RF sniffers either.
I've seen the same problem, again on multiple 350 APs. I wasn't sure whether it was MIC or TKIP but turning them both off fixed the problem.
Based on these responses it doesn't appear that it's just me. I could open another TAC case w/ all of your comments included and manage the resolution w/ Cisco, how does that sound w/ everyone?
What version of NDIS drivers are you using? Also what firmware on the NIC? And firmware on the AP? Reason I'm asking is we are running TKIP and MIC on both 350's and 1200's and DHCP is working fine. It seems when you start enabling these advanced features they seem dependent on the versions of firmware you are running.
We currently have the following:
350 Access Points = 11.23T
350 PCMCIA Firmware = 4.25.30
350 PCMCIA NDIS = 8.2.3
350 miniPCI Firmware = 5.00.03
350 miniPCI NDIS = 3.4.9
I have a customer who had the exact same problem. I was able to reproduce it in my lab by uploading his saved AP config. After a stare and compare of his browser admin pages with another working AP, I was able to determine that when MIC is enabled and compatibility with non-Aironet 802.11 devices is enabled, I am unable to obtain an address from DHCP. This is somewhat expected as MIC is a Cisco proprietary solution to prevent 802.11b suseptability to replay attacks. I'm not saying that this is the same thing that you are running into, but there is a good chance. To disable the compatibility feature, go to Express Setup, make sure that for Ensure Compatibility With: non-Aironet 802.11 is NOT checked. I will notify the TAC Engineer and customer for Case D238955.
I've had problems when WEP (Open), TKIP and MIC are turned on. I finally found out I had the WEP keys reversed. By entering the same key in field "1" on both the client and the AP, and the same key in field "2", my client obtained an IP address with no problems.
I've the same problem too!!!
I am working on a AP1200 with firmware version 12.00T ACU version 5.05001 and NDIS driver version 8.2.3
I have turned on the debug mode on the AP and found that the PEAP authentication is successed but DHCP is not assigned to my client W2K laptop. However, after PEAP authenticate success, I manually disassociate my laptop from the AP (e.g. switch between PEAP and other profiles from ACU), then associate it to the AP again, the DHCP works!!!!
I have tried to disable the MIC features on the AP but seems no difference!!!!!
I also test all previous release of AP firmwares, they don't have such issue!!!!!
I just read these posts after a similar problem, so looks like this thread is still relevant (and helpful). DHCP bombed after I enabled TKIP. I unchecked the "support for non-Aironet clients" box and all is well now. This was with a 350 Bridge with 12.0.4 code and the latest 350 client code.
I have configured PEAP with AP1200 (12.2...13Ja1) and PCMCIA 350 (newest ACU and driver) on WIN 2000 SP4. This is working fine with TKIP/MIC.
If I use a Centrino INTEL Wireless Card 2100B, I get never a DHCP address.
The differences in the LAN Analyzor traces is, the broadcast flag is set to 1 in the Discover message if I use the INTEL card.
I ask the INTEL support and I get a case ID.