I am trying to find a way to disconnect unauthorized hotspot users. We use the Mikrotik hotspot as centralized controller for a number of wifi hotspots. However if a user is not authorized they tend to get a hung session that must be manually removed from the hotspot host list and I'd like to automate this in some fashion.

I tried using this script and various other versions of something similar:
/ip hotspot host remove [/ip hotspot host find where !authorized]

This has no effect. In fact just attempting to get a list of unauthorized hosts using something like /ip hotspot host find where !authorized does not print any results on the CLI (should it?). I can get a list of unauthorized hosts if I use something like /ip hotspot host print where !authorized, but I don't know how to extract the ID out of this to remove the host.

[admin@Mainstreet Office - Ross Test] /ip hotspot host> print where !authorized
Flags: S - static, H - DHCP, D - dynamic, A - authorized, P - bypassed
# MAC-ADDRESS ADDRESS TO-ADDRESS SERVER
0 H 00:26:B9:AD:57:C8 192.168.5.238 192.168.5.238 hotspot1

I also attempted to remove the user using a radius disconnect message (since we have centralized radius authentication/authorization anyway).
However a radius disconnect fails:
# echo -e "NAS-IP-Address=172.17.0.5\nFramed-IP-Address=192.168.5.238" | radclient -r 1 172.17.0.5 disconnect secret
Error message: "Radius disconnect request for unknown ip 192.168.5.238"
(Note that sending the same disconnect message for the host when it is authorized results in the host being properly disconnected)

Attempting to send a DM using the User-Name or Calling-Station-Id instead results in an error message on the Mikrotik that states "Radius disconnect with no ip provided"

I attempted to add additional information such as the hotspot nas port and username along with the Framed IP but this also fails stating that the IP can not be found.

Running v3.30

How can I clear out those unauthorized hotspot hosts without having to do it manually?

You were close with the script, but had too many variables in it, so it could not run properly. Try this out:

Ugh... to simple... that worked.

Any thoughts on why I can't disconnect an unauthorized user using RADIUS?

Turn on RADIUS logging on the router and see what errors it throws.

As I stated earlier the error that is returned is "Radius disconnect request for unknown ip 192.168.5.254".

Unauthorized host: Radius disconnect attempt (this works without an issue if the user is authorized): The Mikrotik sends back Error Code 503 with the above error. Despite the fact that this host shows up in the hotspot shot list with the IP specified.

I can set up a script to boot unauthorized hosts on a schedule, but that isn't as responsive as I would like. With our existing radius infrastructure I'd like to use RADIUS to ensure that there are no issues with the user logging in, without worrying about the delays caused by a scheduled script run.

The user has never logged in, so you are basically asking the router to disconnect someone that does not have an account. I'm not sure you can do what you are looking to do with Radius. They may show up in the host list, but they never had an access request, so they technically can't get an access update and be kicked off.

You can try using the API and have it connect to your router and clear out the table that way. You could also script a server to ssh into the box and run that command every so often. No matter where you place the script and have it run, there needs to be some form of schedule. Having it local just simplifies things a bit more.

I'll explain why this is an issue.

A user that does not have an account see our hotspot and attempts to connect to the internet. They get dumped at our login page which basically says: give us a call and we'll set you up. We set up their service, however since the unauthorized host entry just sits in the hotspot they are unable to successfully log in and use the internet until we manually delete the entry.

I can set up the scheduled removal, however then our customer service staff still ends up potentially waiting with the customer an extra minute or two while we wait for the scheduled script to remove the unauthorized entry.

So while it is not a valid session, it definitely blocks the user from creating a valid authorized host entry which is why I want to essentially flush any unauthorized entries after the user's account is created to ensure that they can then immediately connect successfully.

Why are they unable to log in successfully? What is the difference between a host that is not yet set up and a host that has been set up by you?

They are unable to log in successfully because they have no valid account and so the RADIUS server rejects them.

Once a valid account has been added the Mikrotik is not able to create a new valid host entry in the hotspot until the unauthorized one is removed. We are using simple MAC authentication. For valid accounts the radius server allows network entry and assigns appropriate bandwidth throttling.

When they attempt to load a web page in a browser they should again be redirected to the login page, which would attempt another RADIUS login via MAC address - which should succeed at that point. Then entries you're showing are in the same state as a user who will be able to authenticate successfully (someone you signed up), but hasn't yet.

Either I am not fully understanding what you are saying, or the hotspot doesn't work the way you describe.

To ensure we are on the same page this is what I mean.

Internet service is working for this host: I deleted the user from our radius user database so they will no longer be able to authenticate and then removed them from the hotspot host list.
At this point the host is not authorized and is not able to browse. On the host in question I am dropped at the login page. I am only able to access the login page and any sites added to the walled garden.

At this point I re-added the user to our radius user database and attempted to access google and several other sites once again. I was dropped back at the login page each time. Unless the unauthorized host entry is removed the mikrotik does not send a new authentication request to the radius server. The user will continuously be dropped back at the login page. I have verified this by watching the radius and Mikrotik logs. Until the unauthorized host entry is removed, either through the use of some kind of timeout (kludge that has a greater and more annoying impact on paying customers so we don't use it), a script or CLI action, or Winbox they are unable to gain access to the network. You are correct in stating that once the unauthorized host entry is removed the next network access attempt will trigger a new authentication attempt. The issue is that this does not happen so long as the unauthorized entry lingers.

The script works now with the above clarification, but I really just want to flush any potentially unauthorized sessions when a user is provisioned to avoid any issues.

Is what I have described not the way it should work?

To the best of my understanding that is not how it SHOULD work. If it is how it does work, though, I would suggest you contact support@mikrotik.com and get their opinion.

Authentication by MAC address basically just submits the MAC address as the username and a blank password to the RADIUS server without the user having to fill out a form with credentials - otherwise there is no difference between MAC authentication. On a user credential form if the user fills out the wrong username and password and fails to login, he can try again and - given the right credentials - log in successfully. That's the equivalent to a MAC address not being in the user database for RADIUS, being added, and another log in being attempted. I don't use MAC authentication, but I do use Hotspots with credentials an awful lot. I don't think what you're observing is how the router should behave.

We are using an RB450 in hospot mode to authenticate none Mikrotik equipment. We are experiencing the same issue with users not getting reauthenticated after being disabled by radius. We have put in a script to remove the unauthenticated users from the hosts list. It runs every 15 minutes which works fine for us.

I have exact same problem.
I use hotspot login page to collect infos about client (mac, link-orig) and then I redir them to our registration server (debian, ip in walled-garden) where they must fill registration form (php). After filling required fields and sending form, php execute script which add their mac address to user-manager/radius and from this moment they are authorized with their mac address.
Now they are filling form but later there will be simple form which tell us that they have changed mac address.

But after this steps is hotspot still thinking that they are not authorized. I try to solve it in hotspot settings but unsuccesffuly.
I make this workaround: In last step, after that php tell radius to enable this user, it remove unauthorized hosts from hotspot.

It looks like this in php (Im using sshpass from debian): But Im looking for some more "clean" solution.
PM me for full code.

I have a similar problem,

i have a web to administrate the radius db, i have a form to enable or disable each single user from this db.

the problem is when i disable a user, how i can clear him from host list ?

i mean, without use keepalive timeout or idletimeout, i dont want disturb the rest of users.

any idea?

Try using the Acct-Interim-Interval Radius attribute.
http://wiki.mikrotik.com/wiki/RADIUS_Cl ... ess-Accept

That should get the router to try and re-authenticate the guest every so often, and if it can't, remove them from being logged in. We have never used the attribute so I can't say how it will exactly work in a hotspot setup.

Acct-Interim-Interval only updates the account stats to db.

still no luck with my problem :/

Can you check your RADIUS logs when an Acct-Interim-Interval happens? If I understand the way it is designed correctly, it should show up as either an accept or reject in the logs for that user. Is that not what you are seeing in the logs? It might take another interval for the disconnect to happen as well.

Anything new here? Is it really necessary to remove old hosts using scheduled script (which works fine) or is some setting somewhere?

This work fine!

any more thoughts about this thread, as now in ROS6.20 iam facing same problem with Mac user been hold as posted in first post here.

ip -> hotspot -> server -> (default profile) keepalive = 00:05:00
ip -> hotspot -> user-profile -> (default profile )keepalive = 24:00:00
Note: unreachable unauthenticated user will be disconnected after five minutes and user with successful login/authentication will be disconnected incase of unreachable for 1 day. (Suitable Scenario for Hotel/Motel) for restaurant it will be ip -> hotspot -> user-profile -> (default profile )keepalive = 01:00:00)

ip -> hotspot -> server -> (default profile) keepalive = 00:05:00
ip -> hotspot -> user-profile -> (default profile )keepalive = 24:00:00
Note: unreachable unauthenticated user will be disconnected after five minutes and user with successful login/authentication will be disconnected incase of unreachable for 1 day. (Suitable Scenario for Hotel/Motel) for restaurant it will be ip -> hotspot -> user-profile -> (default profile )keepalive = 01:00:00)

This is not what is the problem, read carefully

You can solve this problem by having a login button on your login page.