wifi roaming

Hello,

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible. 

If anybody else has any info or advice, please feel free to contribute!

maybe this will help collecting some logs, https://community.fortinet.com/t5/FortiAP/Troubleshooting-Tip-Captive-portal-showing-each-time-after/ta-p/288818 

Can you confirm your IP is not changing when roaming between access points?

And can you confirm on firewall's traffic logs you see the same IP after roaming?

I had this same issue.  Are you on a controllerless system such as IAP, or Aruba Central with AOS10, as opposed to a traditional controller?

I know with Aruba Central and AOS10, each AP is the NAS/NAD separately for its connections' RADIUS Accounting.  When a client roams, they get a new accounting session with a new session ID on each AP.

RSSO is a defective RADIUS implementation that disregards session IDs and this causes a "race condition" bug when you roam in a controllerless environment.  If the sessions overlap, you lose the authentication.  Here is an example:

• UserA @ 10.1.2.3 connects to AP1, AP1 sends RADIUS Accounting START, session ID 1
• UserA walks down the hall, causing them to fast roam to AP2
• Two RADIUS accounting events happen at almost exactly the same time:
  • START from AP2 for session ID 2
  • STOP from AP1 for session ID 1
• This is the "race condition" which can go either way: which packet arrives first?
  • If AP1 wins, RSSO sees STOP followed by START and everything works fine
  • If AP2 wins, RSSO sees START followed by STOP, and the bug described below occurs

Session IDs are a critical part of RADIUS.  So in this condition, to any system that respects session IDs, the order doesn't matter.  The end state is that session 1 is gone and session 2 is intact, there is still a session for UserA @ 10.1.2.3.  If AP2's START comes first, there are momentarily two open sessions for the same user/IP pair, until AP1's STOP ends the first one.

However, RSSO disregards session IDs entirely and only keeps one record for each IP/user pair.  So when AP2's START comes in, it just updates the existing record and does not see it as a 2nd session.  Therefore, when AP1's STOP comes in next, it doesn't see it as ending one of two sessions - it only sees one session, which it ends.  The client is de-authenticated until the next interim accounting packet arrives.

I've seen that an FSSO collector agent set up to receive RADIUS accounting data handles this type of scenario better, but have not tested extensively yet.  Note that moving to the collector agent does depend on all the usernames being authenticated matching an on-premise AD.

Have you checked if 802.11k/v/r are enabled in your SSID settings? Those protocols really help the client device understand the network topology and make faster decisions about when to roam. Without them, the client is basically flying blind and will hang onto its original connection for as long as possible.