MAC filter list include statement

If you enable filter by MAC address the MAC address list is stored inside the the etc/config/network file. Anything more than just a few MAC addresses makes the file unmanageable to work with and if you need to include the list across 3 APs it becomes a bit of a headache to match the list up.

Is there any way I can hold a single MAC address list in a txt file and use an include statement in the config file to point to the txt file that I can store in my root directory? That way I can edit the MAC address list on my desktop and simply upload it to the APs each time I edit the MAC address list.

There is no point to use MAC filtering, it is rather easy to bypass. If you want to block some users from connecting to the wifi, then use a secure wpa2 or 3 password.

agree that MAC filtering is basically insecure. However, some of my IoT devices like A/V amp and TV keep forgetting the WPA2 password or refuse to remember the WPA2 password under certain conditions. It really is a PITA to have to keep re-programming them. For example, my LG flat panel as soon as it detects a different Access Point decides to erase the password and prompts for a new one even though the SSID is the same. It's truly madening. The A/V amp is even worse. Always disconnects and refuses to connect unless I re-enter the password. To overcome this I have sectioned these devices off onto a IoT VLAN.

Are you saying that you configure an AP on one device (BSSID), and also on a second device. When the TV sees AP No. 2, it erases the key?

yes. the TV doesn't connect to the wifi then you select the SSID again and it asks for password. It is a known bug with LG TVs.

1 Like

Most likely you cannot include your MAC list directly, but if you are willing to use a script that will do the heavy lifting for you, here you go:

#!/bin/sh

maclist="/tmp/maclist.txt"

if [ -f "$maclist" ]; then

for iface in default_radio0 default_radio1 # List all affected wifi-ifaces here
do
uci delete wireless."$iface".maclist
 while IFS= read -r macaddr
 do
  uci add_list wireless."$iface".maclist="$macaddr"
 done < "$maclist"
done

uci commit wireless; wifi; exit 0

else

echo "First, create a list of MAC addresses (one MAC per line) in /tmp/maclist.txt"
exit 0
fi

You are an experienced user so I don't think I have to explain how it works.

1 Like

by the way: you can find decent OpenWRT Wifi AC routers for 20-40 € once a while, especially previously owned ones.
Both TV and your wifi probably also have a LAN port. Setup router as OpenWRT Wifi-to-Lan repeater and both device issues get solved indirectly. At least the most anoying devices are then solved.

maybe this is not the right forum to discuss TVs but.........I had already thought of all this.

The TV has an ethernet port so me thinking I am smarter than this smart TV decides to use an access point in client mode. However, not known to me then is the fact if you place your access point behind the TV i.e. that the TV is in direct line of your AP client and AP master they refuse to connect. After hours of faffing about I figured out that it was the TV acting as a farraday shield for the wifi signals. Flat panels, especially these new LCD models with "pitch black" contrast that are 40% cheaper than LED models but offer almost identical contrast, use a fine mesh inside the screen which give them their new "pitch black" contrast. Apparently this fine mesh is the perfect farraday cage. Maybe I could put my AP client in front of the TV you might think. I could. But I could also hang my dirty underwear from my balcony.

your script looks interesting. will give it a go. Thanks for the effort.

IMO, while mac filtering is pointless for "security" measures, it does make a convenient way to tell clients which AP not to connect to. Especially in wireless networks where the AP naming is not separated. I still would not advise people to use it as a security measure.

3 Likes

I get your point, but it doesn't tell clients anything other than they can't connect to an access point. Whether the client will try to connect to some other AP is beyond the control of the AP.
It would be better to create new SSID where those problematic devices will connect.

1 Like

Absent of any useful client steering or separate SSID solution, I have found it to does the trick in most cases. Especially with stubborn clients and poor AP steering. But the point of your original post is correct, it definitely does not serve as a good security solution. Especially with clients that now generate random mac addresses upon reconnect; or, those with the ability or knowledge to change their mac address.

1 Like