“Jump the Queue” wireless network with Mikrotik.
Last week I wrote about my latest project, creating a dual-SSID wireless network that allows decent browsing speed for guests whilst ensuring that mission-critical activities get the bandwidth they need.
Part of that strategy was to get almost everybody to use the “public” (VLAN) network, and keep the private network for occasional use only. The reason for that, in this context, is that we have a set of network-connected devices including live Internet video streaming, vision mixer and digital audio mixers that can all be controlled from tablets and laptops. With a large team of volunteers, the password for the private network will be on a lot of devices, and the more technical people are more likely to be heavier data users. As more people pile on to the private network, the advantages of prioritising one network disappear. People are busy, and no amount of reminders or cajoling will prevent people ending up with the private network passwords stored on their phone, tablet and laptop, with each device automatically connecting when they enter the building.
A similar problem arises for small businesses. How do you give priority to the person who needs to upload that huge presentation or have a Skype meeting free from buffering and disconnects, whilst everyone else carries on with their day’s work? The same priority network setup would be a great solution, but there will always be the odd person who believes that whatever they are doing is top priority, and lots of other people who just forget that they’ve got the priority password saved. A smart network admin could modify the router’s QoS based on MAC address or some other criteria, but it will soon get arduous and the chances are they will be away or up to their eyeballs in some other project just when access is needed.
One elegant solution is to use the RouterOS scripting system to rotate the password for the private network. I choose to use a word, let’s say “Bucket”, followed by today’s date in the standard RouterOS format. So today’s password would be “Bucket25oct15”. At 4am tomorrow it will change to “Bucket26oct15”. By making sure that each person connects to the public network first, then to the private network, when they come in the next day their device will fail to connect with their password from the day before and fall back to the public network. This will stop any inadvertent connections, and might be inconvenient enough for Mr or Mrs everything-I-do-is-top-priority from bothering to connect to the private network every day. The first part of the password can be changed periodically if we want to limit who can connect to the private network.
The script below is designed to work with CAPsMAN, but it can easily be modified to work with standard access point configurations. It assumes a CAPsMAN security profile called “security-private”. One thing that took me a while to figure out is that both the script and the scheduler entry must have “sensitive” permissions in order to change a password.
/system scheduler add comment="run the pwrotate script to change the Private password" interval=1d name=pwrotate on-event=pwrotate policy=read,write,sensitive start-date=sep/15/2015 start-time=04:00:00 /system script add comment="Sets the private WiFi password to \"Bucket\" followed by todays date." name=pwrotate owner=admin policy=read,write,sensitive source=":local sysdate [/system clock get date];\ \n:local newpass (\"Bucket\" . [:pick \$sysdate 4 6] . [:pick \$sysdate 0 3] . [:pick \$sysdate 9 11]);\ \n:put (\"Setting Private password to: \" . \$newpass);\ \n:log info (\"Setting Private password to: \" . \$newpass);\ \n/caps-man security set [/caps-man security find name=\"security-private\"] passphrase=\$newpass;"
There are other ideas out there, including generating random passwords and emailing them out to the people who need to know, but I think this simple approach is great when you trust the people who will be using the network. And, of course, there’s nothing stopping the more creative users from writing a script on their device to connect to the private network automatically… and I would be tempted to let them get away with it.