This script comes from the final slide of my recent MUM presentation on RouterOS scripting
It allows you to assign a data limit to trial hotspot users and:
a) have them kicked offline upon reaching this limit
b) create a temporary user to stop them from being able to log back in again
This is a feature which is not available via the current hotspot settings, so I decided to script it into existence. Enjoy!
Just a couple of quick screen shots of the new “Quick Set” mode available in some of the newest releases.
As you can see the dropdown box top left lets you select the mode for the device and puts all the basic configuration options in one place.
AP mode:
And CPE mode:
The addition of a signal strength graph over time is nice and handy for keeping track of the nearby networks you’re going to borrow internet from check connections for when testing this out.
We mentioned this earlier in thebrotherswisp podcast if you missed it, looks like it’s going to make the entry level setup a whole lot easier for those new to MikroTik.
This is a bit of a different post based on some configuration I did just recently to enable the bridging of a Virtual Switch between 2 ESX hosts.
There is an VMWare option for this called a “VMware vSphere Distributed Switch” however this requires one of the higher end licencing packages so isn’t available on the free or basic packages, but there are many different uses you might have for this, from simply creating a temporary bridge while you migrate servers to a remote host, or in my case, creating a bridge network across 2 hosts that use a RouterOS vm as the gateway/firewall for the servers. Continue reading Bridging ESX Virtual Switch Networks using MikroTik and EoIP/Vlan/VPLS
There have been a number of improved netwatch scripts listed on the mikrotik wiki in the past however many of these are hard to understand, broken or both.
I had a request from an associate to assist them finding a solution to fall over VPN traffic from one link to another in the event of an outage; in a network configuration where it wasn’t possible to use the local upstream router as an indication of the VPNs status, so I took the opportunity to revise a netwatch script based loosely on the one located here: http://wiki.mikrotik.com/wiki/Improved_Netwatch_II
My rewrite of this allows both the “up” and “down” scripts to be called from the same place (preferably a scheduler entry) and to be extra nice I’ve commented the whole script so you’re all welcome to modify as you see fit.
This has been mentioned and posted in a couple of places now however I’d like to post a copy here also in the event that anyone else has further suggestions on improvements for the script, or any further questions.
Although I don’t use it much myself, many Mikrotik users would be familiar with the “user-manager” package built by mikrotik as an “all-in-one” hotspot solution for small-medium installs.
Many of the functions in this are automated, however not the addition of per-account rate limits, which would normally be based on the package purchased. Instead most sites opt to use a preset speed value on a per router basis. An alternative option to this would be to put different users in different IP pools and setup a rate-limited queue tree based on that.
I was requested to build a script for use on the main user-manager mikrotik, that would allow accounts to be assigned a rate limit based on the package someone had purchased. Once set, this speed value remains the same.
Although this is sounds like quite a simple task, there’s a lot of work saved in having something like this automated, leaving you to get back to running day to day tasks rather than having to either limit all users to the same speed or worse, keep one eye on your user list to catch any newly created accounts!
With that I mind I wrote the following basic script to allow newly created accounts to be assigned a rate-limit based on the package they purchased.
You can modify the values to match your own options and rework this to your liking.
In this example you can see that, if I user purchased a $30 package (credit-price=30000) they would be assigned a rate limit of 512k/128k, whereas a $90 purchase would get a 2M/128k limit.
#Script to add rate limit's to newly created user-manager accounts.
#Written by Andrew Cox | Omega-00 | http://www.mikrotik-routeros.com
:local counter
:local check
#Loop through all users in user-manager
:foreach counter in=[/tool user-manager user find] do={
#Check to see if comment contains "RLA" (short for 'rate limit added'). If it doesn't, this account hasn't had a rate limit set yet.
#We only check the first 3 characters, this means you can continue to use the comment field for whatever you like so long as you leave the 'RLA' untouched (if present)
:set check [:pick [/tool user-manager user get $counter value=comment] 0 3]
:if ($check="RLA") do={
#Has RLA, rate limit is already set so ignore
} else={
#Doesn't have RLA Set rate-limit based on initial purchase pricing
:if ([/tool user-manager user get $counter credit-price] ="30000") do={/tool user-manager user set $counter rate-limit="512k/128k" comment="RLA"}
:if ([/tool user-manager user get $counter credit-price] ="60000") do={/tool user-manager user set $counter rate-limit="1M/128k" comment="RLA"}
:if ([/tool user-manager user get $counter credit-price] ="90000") do={/tool user-manager user set $counter rate-limit="2M/128k" comment="RLA"}
} }