Thanks for the quick response.

The laptops that have issues connecting to AP2 cannot connect no matter what their distance from the AP. Constantly getting a 169 ip when connecting to AP2, that is until they roam away and connect fine to AP1.

The RADIUS is over the WAN and since we do not have any specific VOIP clients for production at this site, we have not enabled FSR on the APs or on any laptops. The laptops have a company-based core load on them but the wireless NIC properties are Dell defaults.

Hope this helps.

If you ping your radius server, what is the response time? This may be a bit misleading, so do a tracert rad.ius.svr.ip command and let me know how many hops it takes to get to the radius server.

traceroute shows

1 x.x.x.x 0 msec 0 msec 1 msec

2 x.x.x.x 3 msec 1 msec 2 msec

3 x.x.x.x 208 msec 229 msec 315 msec

4 x.x.x.x 314 msec 206 msec 196 msec

5 x.x.x.x 219 msec 209 msec 355 msec

6 x.x.x.x 423 msec 209 msec 314 msec

7 x.x.x.x 207 msec 197 msec 196 msec

Pinging the RADIUS server

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to x.x.x.x, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 236/323/365 ms

Hi. Thanks for the information. Based on what I see, the average round trip it takes to get to your radius server is pretty high. Since it is only data, it should still work. The max times are a little worse of course, so that may explain why you run into roaming issues. If you have authenticated to AP1, then the time it takes to reauth to AP2 may timeout. That would get you a 169 address because you failed authentication. Do your clients support fast secure roaming? You can try enabling this and see if it solves the problem.

I ran into a radius server response problem when I had clients in California authenticate to a radius server here in Michigan. To solve the problem I added a radius server that was closer to them.

May I ask what EAP TYPE and RADIUS server you are using? That may also be a factor. I know on my WLC, you can set an eap timeout value to a larger value to aid with this. I did a brief poke around on an autonomous ap that I had and I didn't see the setting right away. If I run into it I'll post it so you can see if that helps...

Thanks again for your time and persistence.

I do run all autonomous APs and have only cli management interface. We haven't moved on centralized management yet.

The users are not failing authentication...the radius server shows no failures and the APs show associated with EAP (encryption mode ciphers aes-ccm tkip wep128 - leap and peap).

I think the Radius is v3.4, but I am not sure...i know its been updated recently.

Reauthentication works fine on the numerous other client laptops, which should be standard Dell machines with our core load.

I'll check around to see if the users support FSR....I have a meeting with the user in an hour.

Here are the ping and tracert stats on AP1, which users pull a valid IP through everytime. The times may be high simply because we are jumping continents on this one, cuz they seem consistent on each AP.

Tracing the route to RADIUS

1 x.x.x.x 1 msec 0 msec 1 msec

2 x.x.x.x 1 msec 2 msec 1 msec

3 x.x.x.x 234 msec 246 msec 216 msec

4 x.x.x.x 283 msec 215 msec 205 msec

5 x.x.x.x 200 msec 214 msec 213 msec

6 x.x.x.x 223 msec 211 msec 209 msec

7 x.x.x.x 210 msec 219 msec 223 msec

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to RADIUS, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 213/246/326 ms

Both APs have this configured on the Radio 0 interface, if it matters to you.

packet retries 32

channel 2462

fragment-threshold 2338

station-role root

rts threshold 2339

rts retries 32

no cdp enable

infrastructure-client

bridge-group 1

bridge-group 1 subscriber-loop-control

bridge-group 1 block-unknown-source

no bridge-group 1 source-learning

no bridge-group 1 unicast-flooding

bridge-group 1 spanning-disabled

Not sure how much of this helps, but I appreciate your feedback. I'll let you know what happens at the meeting. I am going to get into his machine and test out his settings on the Dell client and if possible load a third party wireless client. We have already done a reinstallation of the Dell wireless drivers and software.

The user works on AP1, but not AP2. Authentication would seem to not be the issue because no one is failing. It's simply not getting/keeping the IP address. Not sure if this would be the dhcp server or if it could be on the client end, but other clients in the same area connect fine to both APs, all while being configured the same on the Dell utility. The DHCP works for some clients on this AP, but not on others, and works fine for everyone on AP1, so it would not seem to be the dhcp.

Talk to you later and thanks again. I will talk to my other network tech and discuss the WLSE options...we have one, but don't use it except for testing. ;)

You could also try saving the config.txt file from AP1. Then editing it so it has the IP address, default gateway, and hostname of AP2. Then push the revised config to AP2. You'd have to double check the channel assignment and power level but at least you'd know the config was the same as AP1...

So the problem was that the switch that the AP was connected to had a configuration on it that caused the AP to only authenticate three users. It was a 'smartport' configuration that gave us the problems.

Thanks for your time and efforts on this issue. Merry Christmas!

Sorry for the delay. The end solution was that the switch was set for a smart port that was configured to only allow a device with three users on it. Therefore, three users connected fine, and any subsequent users were dropped. So configuration of the user and the access point were fine. My network team accessed the switch and fixed the issue with excellent results.

Just thought you might want to know the actual resolution. Thanks again for your time and effort on this one.

Thanks so much for posting up the solution matthoque. This solved our problem.