Disconnect or block a wireless client

Hello

Can anyone tell me how to force a wifi client to disconnect - to temporarily block it from access? I don't mind whether it's via LuCI or the command line.

Thanks

Andy

Well, you could use the maclist filter to block the MAC address of the client in question. Bear in mind though, that if the client is someone who really wants to get into your wifi, the MAC address filter is not a suitable measure to prevent that. MAC addresses can easily be manipulated and then the filter would have no effect anymore.

I think you can use ubus to communicate with hostapd to disconnect a client (for a specified reason) and also apply a ban period.
An example is used in this script. “del_client”.
I think the ban time is in milliseconds.

Thanks both for your suggestions. Both look reasonable - I'm not trying to stop someone hacking in, just wanting to temporarily force a client off the network whilst I investigate something.

silentcreek mentioned the "maclist filter" - where would I find this? Is it available via LuCI? I had a look but couldn't find it - is this via the cli and if so where should I start looking to see how to do it?

The ubus command also looks interesting but I think I'm going to have to go on a documentation hunt to try to understand how to use it. I'll look through the wiki to see what I can find about it - any other suggestions as to where to look?

Thanks

Andy

LUCI :
Network->Wireless
then EDIT button for radio
then scroll down to "Interface Configuration"
Select "Mac Filter" tab

Screenshot_2018-07-25_16-25-27

Thanks!

I have another related question, but I''ll have a look to see if it's already been answered first, and if I can't find anything I'll start a new thread as it's to do with rate limiting not blocking.

If your problem is solved, please consider marking the topic as [Solved] (Click the pencil behind the topic...).

Hello again.

lantis1008 posted a script which gives an example of using the ubus command to disconnect a client. I've been looking at the documentation on the wiki for "ubus" but I admit I don't feel much the wiser. The script has the following in it:

ubus call hostapd.wlan0 del_client "{'addr':'$MAC', 'reason':5, 'deauth':false, 'ban_time':0}"

The Wiki says that "ubus call" "Calls a given procedure within a given namespace and optionally pass arguments to it" but I'm at a loss to know what the "given procedures" might be and how I would find out what the following parameters mean. I tried looking up "hostapd" but what I found didn't seem to be related.

I guess maybe I need to do some more basic reading but I'm not sure where to start - can someone suggest where I should look so I can understand this command?

Thanks

Andy

You can use "ubus list" to find out all of the "modules" (i'm probably not using correct terminology here) that ubus can interface with. On my system there's about a dozen, two of which are hostapd wlan's.
This file in the source code is the implementation of ubus for hostapd:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/hostapd/src/src/ap/ubus.c

Without knowing too much about hostapd itself, but if you've ever looked at how CLI interfaces are written, we should try to look for some kind of struct or set of definitions of the command line options. At line 911 it looks like what we are after. So the list of (current) possible ubus commands for hostapd are:

  • get_clients
  • del_client
  • list_bans
  • etc etc...

These first three are going to be the most interesting for what you want to do anyway. The struct also lists what function is called for each command. Looking at the associated del_client function we can see another struct telling us what things we need to include:

  • Address
  • Reason
  • Deauth
  • Ban Time

This is about all you can glean from this file without digging further into the code and having a deeper understanding.
With a bit of googling we can find out that the "reason" can be one of the reasons defined in the wpa_supplicant source code:
https://w1.fi/wpa_supplicant/devel/ieee802__11__defs_8h_source.html
Looks like they start at line 170.
Now you could google each of those and figure out which one is safest to use (and this also relies on proper client implementation). My previous research has shown reason 5 "disassoc ap busy" works perfectly fine and causes clients to just drop off without too many issues. They immediately try to reconnect though which is where the ban time comes in.

Let me know if there's more that you need or you want clarified. I kind of just spewed information into the textbox here.

The 'reason' is transmitted to the client in a deauth packet and only could affect what the client may decide to do next (try to reconnect, seek another AP, etc). Hostapd will do the same thing no matter what reason code you tell it to send to the client. I'm not sure if reason does anything if you also have deauth false.

In the code, look in ubus.c in your OpenWrt build. The ubus ban mechanism is an OpenWrt extension and is not found in the mainstream hostapd code.

Thank you both - I'll have a go at looking through all the material you've provided.
I'm surprised it's necessary to go looking through source code to figure this out! Is it not documented somewhere? I'm keen on learning more about what can be done with OpenWRT but I admit I'm feeling a bit overwhelmed at the moment.
How did you all start learning this stuff - is there a "beginner's guide" that will help figuring out where to start?

By reading and asking questions.
It might be documented but I couldn’t find it in the first 30 seconds when responding to you. But I knew exactly where the bits of code were. The code tells you exactly what it does. The documentation tells you what someone thinks it does :wink:

Hmmm - I'll press on - though with a little unease. In the world I come from (aeronautical hardware and software development) documentation is king - the code has to conform to the documents, and to be proved to do so - so this all feels rather vague and uncontrolled. Of course, it's a very different scenario - lives depend on our software being correct, and it would be unreasonable to impose such rigorous standards on software like this. I was rather startled by the lack of comments in the source code you pointed me to, though.

I do feel I'm struggling a bit here, but maybe it's just because I'm new to it all - I will persevere. I'll probably be back with a lot more questions, though!