Under certain conditions, the IP addresses of the client devices are reported as 0.0.0.0 in the AP association table. When these addresses are at 0.0.0.0, the AP is unable to ping those devices. This condition exists until some type of network traffic is either sent or received from the device. Once traffic is sent or received, the IP is reported correctly and the device can be pinged from the AP. The same condition exists if the unit goes into suspend. after waking the unit, the association tables reports an IP of 0.0.0.0 until traffic is either sent or received.
A similar issue exists on the dos clients as well. When those units are booted, the IP and Mac addresses are reported correctly. If the unit goes into suspend however; the IP is reported in the association table as 0.0.0.0 until network traffic is sent or received by the device. Once traffic has been sent or received, the IP is reported correctly in the association page.
I had a theory that perhaps the ARP cache of the AP was populating the association table. I went into the CLI and did a show arp to see if I could prove the theory. What I found was that the two tables seem to be unrelated.
We pointed the same devices to a 350 and then to a 1200 vxworks AP and they preformed the way I would expect them to. The Mac and IP addresses were always reported correctly. At boot up, and after a suspend.
The issue appears to be cosmetic in nature unless the customer is in a diagnostic mode and they are trying to ping the clients who have a 0.0.0.0 IP address in the association page. If they ever had a 350 or upgraded from vxworks to IOS, they may spot the issue. Some functionality is missing.
id like to report with our ap350's we can see 0.0.0.0 only on the client side... before upgrading to IOS from vxworks (which by the way, thanks cisco has caused a HOST of other problems with antennas and radios suddenly locking up and having to be rebooted constantly).. Id like to know what the fix is so we can see the ap identification by name and IP that we are associated to from the client software like we used to be able to.
Here we are facing some problems from 350 bridge and work group bridges. We are assigned ip for Ethernet, we are not changing default radio ip i.e. 10.0.0.2. We have assigned 10.0.1.3 to root(i.e access point) and 10.0.1.6 for client 350 WGB.In this scenario we can able to ping to root side systems and gate way of clients.But we are unable to ping to the Root Access point (10.0.1.3).
Same problem here, using IOS 12.2(13)JA1 firmware. It's a real headache trying to troubleshoot a remote site when you can't figure out which AP a problem client is associated to. Also we have an issue with the AP sometimes reporting the IP address from the not-in-use onboard NIC. This is sometimes a previously held DHCP address from when the onboard was hooked up during loading, sometimes a self-assigned address, etc.
Transferring Crash file from standby:
Login to the Active WLC in HA.
(Cisco Controller) >transfer upload datatype crash
(Cisco Controller) >transfer upload filename <Desired filename>
(Cisco Controller) >transfer up...
This is the start of a display filter cross reference between Wireshark and OmniPeek.
The 1st installment is a table of advanced filters. More filters will be added as time allows.
It is a living doc, so check back for changes every so often
Please feel ...
I have created a Powershell script to automatically add a Wireless Guest User on Cisco WLCs. (tested on 2500 Series)
The script should be completely self explanatory.
Powershell SNMP Module (Install-Module -Name SNMP)
SNMP Write Access to...