Client Stuck in DHCP_REQD state

Unanswered Question
Sep 1st, 2011

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
weterry Thu, 09/01/2011 - 17:13

In the first debug that I looked at, the WLC has no indication that the client is sending a DHCP Discover/Request.

We see it pending dhcp (DHCP_REQD does not mean the wlan has dhcp required, it means we are waiting to learn the clients address).

Anyhow, if this is an Open Wlan (no encryption at all?)  then I can't think of any reason we wouldn't be missing the dhcp request, unless the client wasn't sending it....

I'll try to dig deeper in the logs later tonight to see if anything else is odd....    Any chance rebooting the TV does any good?

ThomasPemberton Thu, 09/01/2011 - 17:41

I unplugged the TV for a few minutes and started it back up when I was testing, no luck... I'm new to my job and still learning but from reading through Cisco's documentation I came to the conclusion too that it was never even getting to the point of making a DHCP request...  I let the first log run for a while and noticed at the end it just seems to be looping through the same few steps over and over...  I am going to do some more testing tomorrow with that client and putting another wlan on that AP, try to narrow down some more what is the problem.  After reading through some other similar posts it seems like some people narrowed it down to certain wireless chipsets in devices...not sure what this one is in the TV...

George Stefanick Fri, 09/02/2011 - 06:31

Do you have a firewall between these two devices? Does the apple tv screen sit on "setting time" ?

larnelhight Fri, 09/02/2011 - 08:00

Do you have Client Band Select checked?  I had a similar problem and had to uncheck it until the manufacturer released newer network drivers.  This was for a Mac Pro.

George Stefanick Fri, 09/02/2011 - 09:12

The last issue I had with an apple tv was that the dam thing wanted to go out to the internet and get NTP time.

What is your security again ? None right ?

All other clients work fine right ..

TV is SET FOR DHCP, right?

ThomasPemberton Fri, 09/02/2011 - 09:16

Once the MAC is registered on our system, we have no encryption, webauth, etc on our wireless.  When I was testing this there was about 10 other clients on the AP with no problems.  TV was set for DHCP.

ThomasPemberton Fri, 09/02/2011 - 09:51

debugging a client that works, it seems to break at the very last step of the PEM, sending an XID frame...on the client that works :

*pemReceiveTask: Sep 02 11:30:12.577: 00:19:d2:6b:0c:f4 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0

*pemReceiveTask: Sep 02 11:30:12.577: 00:19:d2:6b:0c:f4 Sent an XID frame

*DHCP Socket Task: Sep 02 11:30:13.606: 00:19:d2:6b:0c:f4 DHCP received op BOOTREQUEST (1) (len 308,vlan 27, port 13, encap 0xec03)

broken client:

*pemReceiveTask: Sep 01 15:18:19.646: 00:19:9d:6a:09:6d 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0

*pemReceiveTask: Sep 01 15:18:19.646: 00:19:9d:6a:09:6d 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0

*apfMsConnTask_4: Sep 01 15:18:32.812: 00:19:9d:6a:09:6d Association received from mobile on AP 8c:b6:4f:c8:b1:90

(loops back to start of process)

George Stefanick Fri, 09/02/2011 - 09:55

So the broken client stops right as asscoaition received and nothing else comes after that ?

What are your PHY rates set at ... what is mandatory and supported ?

George Stefanick Fri, 09/02/2011 - 10:24

no worries ... we are here to help ..

On the WLC main page ... click on wireless... then on the left you will see 802.11b/g/n (bottom lower one). Then click on network ... take a sreen shot of that for me ..

George Stefanick Fri, 09/02/2011 - 10:36

I dont know if this is your issue, BUT we could try it ... Make 1 mandatory... and 5.5 supported and see what happens.

Also, can you do a complete debug from the Apple TV ...

ThomasPemberton Fri, 09/02/2011 - 10:39

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?

George Stefanick Fri, 09/02/2011 - 10:42

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

weterry Fri, 09/02/2011 - 10:50

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 Fri, 09/02/2011 - 10:40

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

ThomasPemberton Fri, 09/02/2011 - 10:42

+ TV Make/Model: Vizio

E3D320VX

+ Firmware Version: 1.22.8.0874 (Latest version from Vizio

)

George Stefanick Fri, 09/02/2011 - 10:48

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.

ThomasPemberton Fri, 09/02/2011 - 10:55

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

daviwatk Fri, 09/02/2011 - 11:05

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.

ThomasPemberton Fri, 09/02/2011 - 11:55

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

daviwatk Fri, 09/02/2011 - 13:26

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.

ThomasPemberton Fri, 09/02/2011 - 13:29

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

weterry Fri, 09/02/2011 - 13:39

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

weterry Fri, 09/02/2011 - 14:02

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?

ThomasPemberton Fri, 09/02/2011 - 14:12

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

weterry Fri, 09/02/2011 - 14:19

I'm only speculating the spectrum thing in the association is why the client is doing what it is doing...

Maybe they can figure out how to update the wireless driver on that box if it hasn't been done before...

but I dont see anything wrong from a Cisco Wireless perspective in either the Capture or the Debug....

And believe me, I was really hoping to have an excuse to go get me a new TV with wifi for "testing"

ThomasPemberton Thu, 10/13/2011 - 14:52

Well after some more digging it looks like we have about 20-30 clients displaying this behavior...they all hang before the DHCP request is sent out...

ThomasPemberton Thu, 03/29/2012 - 11:04

No I never got the TV working.  I did find for the similar Wii problem we were having, that you must make 1Mbps and 2Mbps mandatory to get them to work on the wireless.  The IT support for dorms did not want to turn this on as yes it will fix Wiis, but can cause other problems with wireless (people hanging on to a weak signal, etc) - they decided to leave those rates disabled. 

maurice-james_2 Tue, 02/19/2013 - 12:09

Our issue was identified as hijacked rogue DHCP relay agents that received DHCP NAK packets from the DHCP Server.

The reason for rejection was “requested address not available”. The rogue relay agents then broadcasted the zero address (0.0.0.0) to the device. It appeared in the device, the previously obtained IP address was blanked out with 0.0.0.0. The rogue relay agents repeatedly attempted to discover the new DHCP address to the DHCP server but the DHCP server already shut them out and not even responding to the rogue relay agents requests.

Check the ip helper-address configured on your client, AP. and/or WLC vlan interfaces. Is there one: If so,is it needed?

Check your client, AP, and WLC vlans and ensure that the DHCP request is originating from the proper vlan / subnet and is not being hijacked and originating from a vlan / subnet with an improper or no DHCP configuration. This may happen if the subnets in question are not full /24 subnets and DHCP helper addresses are configured on one or more them.

Actions

Login or Register to take actions

This Discussion

Posted September 1, 2011 at 4:17 PM
Stats:
Replies:34 Avg. Rating:
Views:4848 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard