WLC 6.0.196 and Symbol DHCP issue

[wififofum]

Hi folks,

I've run into an annoying issue with 6.0.196 with my favorite (Motorola/Symbol Fusion) client.  Ever since some testbed controllers were upgraded, Symbol MC90 handhelds have been unable to roam successfully across controllers.  The EAP-TLS client session state is seen as Mobile on the Anchor, with its "home" IP retained on the "foreign" controller, but IP connectivity is lost.  I have also seen the reverse (new controller's IP, but still in Mobile state).

All controllers are using Symmetric Tunneling and control/data paths appear up (mping-able).  When the clients return to their "home" controller (where their cradles are) they are once again reachable.

There is this bug on the last page of the Release Notes.  I have been told its classified as Unreproducible.  Has anyone else seen this behavior?  Debugs indicate the client may not be doing a full release/renew,  but, you guessed it, "it worked fine before" under 4.2.

6.0.196 Release notes

http://www.cisco.com/en/US/docs/wireless/controller/release/notes/crn6_0_196.html#wp621183

CSCtf12055

Symbol HH cannot get DHCP while coming out of sleep mode

I have seen some interesting messages in the msglog:

*Mar 16 02:59:34.452: %APF-3-PDU_ENCAP_FAILED: apf_net.c:786 Failed to encapsulate a PDU for transmission to station 00:15:70:d3:3b:b2. Destination IP address not set in L3 mode.

This begs the question: when a roaming client’s session timeout expires, is the client still mobility-tunneled, or is it then supposed to become a local-controller-managed session?  Are there any changes to the default mobility-tunneling behavior in 6.x? 

What I see are successful roams with retained IPs, but no IP connectivity.  Are there any diagnostics I can run to confirm a successful CAPWAP client data path?

I am hearing that other folks are actually downgrading code due to this issue.  That doesn’t seem acceptable, given the drivers to move forward to 6.x. 

Also getting a lot of these messages in the msglog.  Have tried disabling DHCP Proxy to no avail.

*Mar 16 09:45:15.755: %DHCP-4-RELAY_SERVER_NOTGET: dhcp_proxy.c:2216 Unable to get the dhcp relay server's ip address

Thanks all,

[wififofum]

To roll the ball further:

Session Timeout is 7200s - considering lowering this back to 300s to discouragelong-lived sessions and inter-controller roaming..

DHCP Lease Time is 16 Hours.

[Scott Fella]

The favorite scanner issue..... I have seen that in the past, but not had any upgrades to 6.x yet.  Do you still have issues if the scanners have a static address?  Have you tried to set the scanner so that it is always on and doesn't go to sleep?  In most of my installs I have alway made sure they keep the scanner power saver off.  Yeah they have to train the users to swap the battery during their lunch or dinner.... better than having users complain:)

[wififofum]

Thanks Scott,

I think that's the simplest intervention.  I had hoped Symbol had made a CCX-compliant client by now. There's a few other 6.x bugs around WLAN anchoring but it doesn't appear to be impacting any other device.  These handhelds are the most mobile devices we have, so would be the most prone to such an issue.

We'll see how it goes.

Regards,

Bruce Johnson

[Scott Fella]

Hope it works.... it has saved me in the past for sure.... my clients looks at it this way... they would rather spend the money on extra batteries and charges and train the users on swapping batteries than having upset users who just ends up breaking the scanners:)  Especially when they move from paper to scanners.... no one like changes:)