AP541N wireless clients sporadically not acquiring dhcps

[cascoli_2008]

I was having this issue with my Dell Precision M70 laptop until I made this tweak to the Intel Pro Wireless 2200BG card that is built-in and so far its seems to be making a difference with it connecting to our Cisco 541L APs and acquiring a DHCP from our network.  However, the only thing different I noticed after making this change is that it is initially a bit slow at connecting to the Cisco APs.

http://www.intel.com/support/wireless/wlan/sb/cs-006205.htmUse Intel® PROSet/Wireless WiFi Connection Utility to Set CAM1.     Click Advanced > Adapter Settings > Advanced tab. 2.     Select Power Management and uncheck Default / Auto and move the slider to Highest / Maximum Performance.If the slider is already at Highest / Maximum Performance, move the slider to another setting and then back to Highest / Maximum Performance.

We are still experiencing this issue with our Dell Latitude E4200 laptops but need to verify that they are using the latest wireless network adapter drivers.  In addition, I am planning to tweak the PSP as I did with the Intel Pro Wireless 2200 BG.

F.Y.I. Our PDC and Primary DNS server is a Windows Server 2000

         Our BDC, Secondary DNS and DHCP server is a Windows Server 2003

Any help or suggestions would be greatly appreciated!

Sincerely,

Carmine

[neilrobbcisco]

We were just about to purchase x2 AP541N but these DHCP issues worry me.

Can anyone recommend another Cisco AP that I can cluster and is stable for a small business just now? Our Cisco / Linksys WAG54G2 Wireless-G ADSL2+ Modem Router will be acting as DHCP with both APs connected to this router via PoE. Just going to have x1 SSID with about x10 802.11N clients.

[dmaloney-rn]

I read this whole thread, and tried virtually all of the fixes suggested, but none of them worked for me. The solution I found had nothing to do with the APs themselves, but I wanted to post my solution, because my problem fit the problems posted here to a T.

I had two AP-541Ns, both connected to a Cisco ESW-540-8P (8 port gigabit switch w/POE). The APs seemed to work perfectly at first, but as we got more wireless clients connected to them, we started to notice that after 4 or 5 clients were connected to each, the clients stopped being able to get IP addresses.

The cause of the problem turned out to be some (to me) obscure per-port "security" settings on the switch. I think they were limiting the traffic per port to a certain number of MAC addresses. As soon as I disabled that "security" the problem vanished completely.

So the moral of the story is - pay attention to the switches the APs are connected to, as they may be causing the problem, it's not necessarily the APs themselves.

Good luck!

[FrederickWhite]

David I have this same setup as you and the same issue.  Can you elaborate on the obscure per-port security you found that fixed your issue?

Thanks

[mpyhala]

Frederick,

You probably need to configure the port that the AP541N is connected to using Smartport Roles. The port should be configured for Access Point. Please see page 22 of the Admin Guide for details:

http://www.cisco.com/en/US/docs/switches/lan/csbms/esw500/administration/guide/ESW_500_Administration_Guide.pdf

[dmaloney-rn · Accepted solution]

The setting on the Cisco ESW-540-8P (8 port gigabit switch w/POE) I found that worked for me is:

--> Security --> Traffic Control --> Port Security

By default, all ports are set to "Locked / Limited Dynamic Lock / 3 / Discard / Enable / 60"

I simply edited (click the "edit" button to the right) the ports on which I had my WAPs and unchecked "Lock Interface."

That did the trick for me.

Best of luck - hope it works for you, too!

[Christopher Adlam]

For all following this thread, there is now a new version out, 2.0.4.

Release notes state:

Caveats for Version 2.0.4

Closed Caveats

CSP #535465—A client wireless station was continually requesting a DHCP

address. The server sent responses, but they were not seen on the wireless

interface.

In the 2.0.1 release, the TX FIFO that handles multicast traffic when the AP goes off

channel to scan for other APs was disabled. However, it is necessary to disable all

the TX FIFOs when the AP goes off channel to scan for other access points. If the

AP submits packets to the TX FIFOs when the AP has hopped to another channel

to scan for beacons, the wireless chip microcode can stop outputting packets.

The AP regularly scans for access points when clustering is enabled or when

rogue AP detection is enabled. When Clustering or Rogue AP detection is not

used, the AP does not hop off channel to detect other Access Points. The AP541N

does do aggressive channel scanning during the first two minutes after the AP

boots up to quickly generate a table of potential rogue APs, but only does this at

boot time and then does not perform another scan unless the Rogue AP or

Clustering feature is enabled.

CSCub73520—Resolved the issue of DHCP handling between the access point

and the DHCP server when Clustering or Rogue AP Detection is enabled.

[StanG]

Just to let you know that we have this problem (client does not get DHCP lease, until we reboot AP).

This happens on the latest firmware: 2.0.4

     AP541N-K9-2.0(4)  

I'll try the registry fix on our Windows 2012 R2 DHCP server, and have just disabled the broadcast limiting settings.

[StanG]

The registry setting (IgnoreBroadcast = 1) had to be removed or set to 0, no DHCP lease was getting through.

I hope that setting the Broadcast rate limits to disabled, and disabling Rouge AP detection will fix this problem. Otherwise we will set a new different AP (not a cisco one).