- Bronze, 100 points or more
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
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