We rely on radius for authentication and we had a client that was online with radius for several weeks, but we removed them from our radius so they would get an access-reject on reauthentication...
But we just realized that for some reason their radio is online still over a week later.
Whats odd is we can see on the AP that they did get rejected during a reauth, but are still connected! This is a huge issue.
Rebooting the client SM, and now they are getting rejected properly and aren't getting online, but that should have happened naturally during a session rereg/reauth, like I said as you can see below the client is still connected since 63 days, even though radius state is showing "request denied"
Is this mechanism something you've used in the past to disconnect a client and has worked correctly? (i.e. has removing a customer from radius worked as intended and given them an access-reject on re-auth, but this was an isolated incident?)
If you happened to have pulled any logs from the client before rebooting it those would be helpful. I'll talk to someone in test about reproducing this issue in our lab, but we hadn't heard of anything like this previously. Thanks for the info, and we'll get back to you if we find anything.
We’ve used it in the past and never had an issue, this is the first time we’ve seen the radius showing denied while the client still connected.
Thought this is one of those thing that’s hard to verify because you have to wait for the reauth to occur and see what the AP does to the SM
But like I said we use it for hundreds of clients a week and never got complaints before but not sure if this is because the CSR noticed something odd was up this time and just missed other times it happened.
No I didn’t get logs as people were quite upset as the customer had supposed to been disconnected for a while.
Well, the good news is our team in India was able to reproduce it overnight, so we’ve got someone tracking the issue down. Seems it may have cropped up during 15.2 development.
Not so good news is it’s most likely too late to make the cut for 16.0.1, but we’ll make sure to fix it in the next release. In the meantime, I’d suggest forcing a reboot of the SM after removing it from Radius as a workaround until we can get that fix in a build for you.
Ouch this is a nasty bug, as we rely on it HEAVILY, and manually rebooting hundreds of devices each week really isn't an option. Is it a constant error or something that will only affect certain people?
No chance it slips into 16.0.1 :( I thought it had another week or so of testing to go XD
We would really like someone to validate this fix as soon as possible. We are a few weeks away from release on 16.1, but don't have a lot of feedback from Beta users yet.
