cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
17852
Views
0
Helpful
34
Replies

Client Stuck in DHCP_REQD state

ThomasPemberton
Level 1
Level 1

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

34 Replies 34

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?

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 ...

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
___________________________________________________________

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.

.

daviwatk
Level 3
Level 3

Can you post the exact model of this TV so, perhaps, we can determine exactly what specs it's WiFi connection has.

+ TV Make/Model: Vizio

E3D320VX

+ Firmware Version: 1.22.8.0874 (Latest version from Vizio

)

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.

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
___________________________________________________________

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...

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 " when it has associated so we can see some more info about it's connection.

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

attached is a wireless cap i did with my laptop...just from a quick look and didn't see much...

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.

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...

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"?

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?

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

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: