When roaming from one AP to another, dropping telnet sessions

[david_howard_h1]

We have a 5 week old Ruckus install. All firmware is current. Over the last 8 days, we have started to experience telnet sessions dropping and resetting our people in a specific application when they hand off from one AP to another (which causes the app to hang and Administrator intervention is needed to resolve every time). Prior to 8 days ago, this was not an issue. Yes, we've looked at Windows updates (we even rolled back test machines to July of this year). Still the same issue. Is there a chance that a long term setting (like channelfly or something) is causing this to start happening because it took time for said setting to do it's job? We're past the basic troubleshooting, we're having to get into the "odd, nobody thought of that" category. Yes we have a ticket open with support, but we're not moving forward much over the last 4 days on that front. Anyone?

[david_howard_h1]

Hello Alex. Thank you for the questions. Although my answers to 1,2 and 3 are "no" it did get me to think of a follow up line of thoughts. If we're on a DHCP environment and the hand off occurs with a 2 second delay, could it be trying to "get a DHCP address" even thought it already has one (thus getting the same one back), causing the drop? Hmmm, it's silly thought even as I see it in print, but I'm trying to think of something crazy that might actually lead us into the right path. It could just be that a 1-2 second handoff delay is simply dropping Telnet connectivity, but again WHY is it only doing that just recently is still the biggest aggravation, lol.

[alex_shalima]

Hi David,

My answer would be - something changed and you are not aware of it.

You might be on something here. Unless there is a change on Layer 1 (physical connection) and/or Layer 2 (VLAN change) during roaming the only other reason for a client to get a new DHCP lease is because one of the DHCP packets never made it there. In that case the client will ask for a new IP, hence causing Layer 3 stack to reset.

Do a packet capture on your Gateway to make sure you're not dropping/filtering or mis-routing any packets for your DHCP. 

Another idea would be to static an IP on a client device and try roaming again. That would exclude DHCP server from the equation completely.


Best,
Alex

[jakob_peterh_ns]

If your can tail your DHCP log, that should be easy to see.
DHCP clients normally ask for a confirmation of the IP after any network changes, so if the IP stack thinks the network 'changed' during the roaming between AP's, you will see a DHCP Req, Response & Ack in the log.If you're on a unix platform, tail -f /var/log/dhcpd | grep -I

One possible issue:
You have one or more AP's with a broken VLAN on the uplink, that still broadcast the SSID for it (as it does not test if the SSID VLAN works)But you should see that on the client, as the DHCP address changes from your lease IP to a self assigned one.
If you're on a new macOS device, the Airport icon in the menu will show an exclamation mark when that happens.

Check & re-check VLAN tagging/trunks everywhere, or trace your devices MAC on the system when the connection mess up.

[jamie_walmsley]

if your using an 802.1x SSID try enabling 802.11r fast roaming as that should help with seamless handover as the client isnt having to reauth against RADIUS on every handoff. (I'm assuming you've applied the relevant Krack patches before enabling 802.11r)