09-01-2011 04:17 PM - edited 07-03-2021 08:39 PM
User is connecting to 5508, running 7.0.116.0. Previously worked on another AP. TV (client) is set to use dhcp. As other posts have mentioned, "DHCP Addr. Assignment" checkbox is not checked for this wlan, but I also switched it to Required for this wlan but it did not make any difference. Seems to be a problem with just this client as many other clients are on this AP with no problems.
Users have to register their MAC to get on our wireless system, but there is no encyption or security enabled once the device has been registered.
See attached logs, let me know if you need any more info on my setup!
Thanks
~Tom
09-02-2011 10:39 AM
User is gone today, but Tuesday I am going to stop by again, Will give that a shot. I attached to debugs from the controller in my first post (debug client xx:xx:xx:xx:xx:xx)...is there some other method of debugging that I should try?
09-02-2011 10:42 AM
I have notes from my t/s with the NTP issue. And i have it mentioned 1 PHY rate needs to be mandatory. I have 1 mandatory on my lab and its working.. Im not in front of my lab to test at the moment.
But that is a difference between your set up and mine ...
09-02-2011 10:50 AM
Talk about an Active Thread....
As far as I'm concerned, the Client Debug clearly shows the TV is associated and never sends a DHCP Request. (it just associates again and again after a few seconds in limbo). I know this gets complicated, but if it were me, I'd get a wireless capture and prove the TV is or isn't do that... Maybe it sends it and it ins't making it to the WLC, but that doesnt make sense (would be a serious problem though).
By the way, client debug shows data rates:
*apfMsConnTask_4: Sep 01 15:18:32.812: 00:19:9d:6a:09:6d STA - rates (10): 139 12 18 150 24 36 48 72 96 108 0 0 0 0 0 0
Which translates to 5.5M 6 9 11M 12 24 36 48 54
I think this matches the screenshot from the WLC config.
Either this TV isn't trying to send any packets or its packets are getting lost somewhere.....
Any chance you have a wireless sniffer?
What about a Windows 7 laptop? With win7 you can follow https://supportforums.cisco.com/docs/DOC-16398 and you might be able to get a half-decent wireless capture...
That or a TAC case might get you some official TAC assistance when OmniPeek Remote Assistant.
.
09-02-2011 10:40 AM
Can you post the exact model of this TV so, perhaps, we can determine exactly what specs it's WiFi connection has.
09-02-2011 10:42 AM
09-02-2011 10:48 AM
looking at your debug ... not sure its the man rates... but still good to try ... also do you have aironet extentions enabled? if so you might want to disbale them.
09-02-2011 10:55 AM
Aironet IE is enabled on this WLAN. Will probably still try the rate change...contacted user and going to check it out now...
no wireless sniffer but my laptop is Win7...
09-02-2011 11:05 AM
FYI: it shows 802.11n (Single Band) for this TV, from Vizio's site. I second the removal of Aironet Extensions on the WLAN; no telling what this device is capable of.
Debug shows it is hitting your 2.4Ghz radio.
You may also consider disabling B, either globally in radio policies if feasible, or on the WLAN itself. If you don't have any B clients, you could just disable your B rates globaly, and maybe start with 6, 9, or 12Mbps as mandatory. This should not have an affect on your client performing a DHCP discover, but just for the most efficient connectivity.
Can you post a ">show client detail
09-02-2011 11:55 AM
No luck on disabling Aironet IE or data rates
client detail...
(Cisco Controller) >show client detail 00:19:9d:6a:09:6d
Client MAC Address............................... 00:19:9d:6a:09:6d
Client Username ................................. N/A
AP MAC Address................................... 8c:b6:4f:c8:b1:90
AP Name.......................................... Reshalls-TS829
Client State..................................... Associated
Client NAC OOB State............................. Access
Wireless LAN Id.................................. 4
BSSID............................................ 8c:b6:4f:c8:b1:90
Connected For ................................... 36 secs
Channel.......................................... 6
IP Address....................................... Unknown
Association Id................................... 2
Authentication Algorithm......................... Open System
Reason Code...................................... 1
Status Code...................................... 0
Session Timeout.................................. 0
Client CCX version............................... No CCX support
QoS Level........................................ Silver
802.1P Priority Tag.............................. disabled
WMM Support...................................... Enabled
Power Save....................................... OFF
Supported Rates.................................. 5.5,11.0,6.0,9.0,12.0,18.0,
............................................. 24.0,36.0,48.0,54.0
Mobility State................................... Local
Mobility Move Count.............................. 0
Security Policy Completed........................ No
Policy Manager State............................. DHCP_REQD
Policy Manager Rule Created...................... Yes
ACL Name......................................... none
ACL Applied Status............................... Unavailable
Policy Type...................................... N/A
Encryption Cipher................................ None
Management Frame Protection...................... No
EAP Type......................................... Unknown
Interface........................................ vlan 198
VLAN............................................. 198
Quarantine VLAN.................................. 0
Access VLAN...................................... 198
Client Capabilities:
CF Pollable................................ Not implemented
CF Poll Request............................ Not implemented
Short Preamble............................. Implemented
PBCC....................................... Not implemented
Channel Agility............................ Not implemented
Listen Interval............................ 100
09-02-2011 01:04 PM
09-02-2011 01:26 PM
There's something weird going on with your TV. As you stated, the TV will associate, authenticate, then it just sits there. After doing nothing for ~10 seconds, it probes for a little bit, then comes back to associate and authenticate.
This TV is not making a DHCP request, period. Not sure about all these fancy new TVs and their built-in wireless, but can you provide a static IP to the TV? Do you have other TVs that are working fine? Something is definitely not right with this one.
09-02-2011 01:29 PM
This is actually on a college campus, so there are a variety of devices in rooms. The area that directly supports the dorms said that they have actually seen this behavior on certain devices (older Wiis for example). Another thing that bothers me - this person can connect to an open (non-university) network next door and the DHCP on the personal router will work fine...
09-02-2011 01:39 PM
Man I'm ecstatic to see that not only did you start this thread with client debugs, you were also able to get a capture when we asked for it! Let me just say Thank You, since it really helps rule out unknowns.
Now, as David said (he beat me to it), this device is never sending a packet after Association, and I have a theory...
Someone once told me the following:
A [client] with dot11SpectrumManagementRequired set to TRUE(1) shall not operate in a BSS or IBSS unless the Spectrum Management bit is set to "1" in the Capability Information field in Beacon frames and Probe Response frames received from other Mobile units in the BSS or IBSS.
So it just so turns out, this device sets the bit to TRUE in the association request, and our APs have it disabled.
I'm trying to investigate further if this really is the reason (sounds plausible) and if so, how do you work around it...
I'd try just disabling WMM as a quick check, but then you'd entirely lose .11n on this wlan....
Anyone else out there know anything about this "dot11SpectrumManagementRequired"?
09-02-2011 02:02 PM
Ok, as I was thinking, I've only ever seen dot11SpectrumManagementRequired in reference to DFS which is a unii2 5Ghz thing.... where this bit enforces certain dfs parameters...
In the previous case, enabled DFS "channel switch announcement" resolved it.
But this is 2.4Ghz that you are dealing with, none of that should be relevant. So I honestly have no clue why that bit is set by your client (unless we didnt something to make him think he needs it???)
Are we sure this device was working before?
09-02-2011 02:12 PM
After talking to another networking guy here earlier today, he said he could not find any record of it have gotten in IP in the last year. I also e-mail the user and they said that it "might have been on a non-university network" in the user's old dorm room...
P.S. Glad I could provide the information needed I worked in end-user support before and know how frustating it is when the user just says "well I think I did A, B, C...Fix It!"
~Tom
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: