cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
696
Views
0
Helpful
6
Replies

WLAN Controllers and IP Auto-configured clients

Andrew.Hanson
Level 1
Level 1

We have an open access SSID that supplies no DHCP services. The valid network range is to be the ip address of autoconfigured clients (namely Microsoft's 169.254.x.x). When I associate to the WLC no problem. My client settles on an address (with the limited connectivity warning) and shows connected to the WLAN. However, the WLC shows the client Associated but not authenticated. The WLC also does not display the autoconfigured IP address, just 0.0.0.0. The only way communication will succeed is if I statically assign a valid address (private or public) other than the 169.254.x.x address range. Then no problems. Has anyone else experienced this? If so is there any way to make it work using the autoconfiguration ip address range? Thanks! Drew

6 Replies 6

scottmac
Level 10
Level 10

Is all of this happening in tehe same broadcast domain / VLAN?

Did you verify the subnet mask on the WLC?

Do you have any authroization enabled?

IF these clients will be talking off-LAN, how are you setting up the default gateway (or not)?

Let us know

Scott

Hey Scott, thanks for taking the time.

Yes both same broadcast domain. Subnet masks were the same. No authorization explicitly defined. No default gateway neccessary. I did configure the WLC interfaces with the autoconfigured address 169.254.x.x /16. Same as the client. They could ping each other but not the client. In the WLC details for the client the client IP was displayed as 0.0.0.0. The WLCs could ping each other no problem. Even when I staticly assigned a 169.254.100.100 /16 on the client he could still not ping either WLC interface. The only time I could get successfull communication is when I address the WLC's interfaces and the client with a non autoconfigured (169.254.x.x) ip address. You asked about authentication, in the details of the client when it was addressed with the Microsoft autoconfigured address, the client details indicated that DHCP_REQ policy was in place and that the security policy was not satisfied. I checked the definition for the WLAN and the DHCP required was NOT checked. Is the WLC detecting the DHCP broadcasts and reliazes that the client does not have an IP address? So he does not allow him to fully associate? Because also in the client details he indicates Associated but NOT Authenticated. Even though the WLAN is defined as Authentication OPEN / Encryption Disabled.

Sorry to dump so much on you. Thanks!

Can two clients with the 169.254 addresses create an Ad HOC session (Peer-to-Peer)?

It sounds more like a client-side issue ... are you using Zero Wireless Config, or the software utilities that came with the NIC?

Maybe try the other (utilities if currently using ZWC, ZWC if currently trying utilities).

Have you tried a scan of the Microsoft forums? Anything there? Or are these something like handheld scanners?

I'm curious as to if you were to hard code the 169.254 addresses in the Alternate Config (the tab behind DHCP that let's you put in an address to use if DHCP fails - instead of taking the "autoconfig" values)

If that works (169.254.x.x in the Alternate Address tab) but the same series of addresses provided by autoconfig fail .. it has to be a client-side issue... especially with the warning baloon saying "Limited or No COnnectivity" ... maybe Microsoft gundecks the traffic for anytihing but AD HOC.

It might also be worth trying to get a Wireless "sniff" trace to see what traffic is actually being passed. I believe Wireshark (Ethereal) and a wireless flavor of WINPCAP can grab that traffic (and it's free).

I really don't know, just grasping at straws here. You've found a good one ....

Give it a shot and let us know.

Good Luck

Scott

Hey Scott,

Hmmm, interesting thought on the AD_HOC capability! I'll have to see if they can at least communicate with each other, I suspect they will though. Let me answer your questions:

1. Yes, ZWC was being used.

2. Rough scan on MS forums for autoconfig nothing jumps out as to conflict with Cisco WLC interaction.

3. I've not tried hard coding the Alternate config. We were hoping to allow users to simply associate to this DMZ wlan/lan and not have a need to furnish any network services on it (thus the autoconfiguration).

4. I've tried statically assigning the 169.254.x.x address to the NIC and it still could never communicate with the WLC interfaces established in that VLAN. The interesting part was the the Status gui on the NIC indicated packets being sent out but nothing was coming back from the infrastructure.

We've just gotten Network Instruments monitoring solution, however still haven't had a chance to install. Maybe now is a good time!

One more tidbit, if I plug the client into a wired lan connection and leave him with the autoconfigured IP it works just fine. I'm suspecting that the WLC's are not recognizing that the autoconfig address is "valid" OR the MS client (in our case laptop w/XP) is not passing this information to the WLC's to satisfy their security policy of DHCP_REQ.

Question: The DHCP_REQ displayed on the WLC's client details was indicated even though I had deselected the DHCP Server Required option on the WLAN configuration. Is the WLC indicating this on my client because he is detecting the DHCP broadcasts from the client? I've got it working but it would sure be nice to KNOW WHY! Hahahah.... Thanks again Scott for taking the time to listen to the rambling!

Sincerely,

Andrew

Andrew,

Do you by chance have any other controller interfaces using the same classful address range (A/B/C) as the clients? I know there was a controller bug related to this.

Hello B,

Yep, we have two 4400s, each had an interface in the 169.254.x.x address space. They could ping each other but not the clients. In what way was the bug related?

Thanks,

Andrew

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: