I have made a walled garden for my non-paying customers as a replacement for my old method of disconnecting them. We however have a LNS cluster so I need to add and remove the Addresses form the address list on 10 routers. This part was easy.
the problem im having is for some reason, sometimes, the addresses don’t remove! Its very annoying and I cant figure out why.
now I thought it could have just locked up on one router, but, it does not remove it from any.
API SCRIPT: [when I want to remove a single IP from the overdue list]
$ipAddress='192.168.1.1'; //ip from billing_script
$API->write('/ip/firewall/address-list/print', false);
$API->write("?address=$ipAddress");
$API->write('=.proplist=.id',false);
$tarefas = $API->read();
foreach ($tarefas as $tarefa):
$API->write('/ip/firewall/address-list/remove', false);
$API->write('=.id='.$tarefa['.id']);
$API->read();
endforeach;
Running my script that flushes all IP’s off my address list (and then re-adds them) works, but I don’t want to do this every time, that’s a lot of load on the routers.
Try to use the argument “=numbers=” or the “remove” instead of “=.id=”.
Better yet, I suggest you upgrade RouterOS to at least 6.7 (if it’s not there already) and instead of removing expired entries, when adding them, use the “timeout” argument to specify a duration, after which the item will be automatically removed by RouterOS itself.
We use 6.12 across the network, some devises still run 6.9 and a few run later releases. However, an ‘expiry’ will not work well for what we use it for, we want to re-enable the internet for users as soon as they pay, not hours later with an automated update, not when it should just be a simple API function as above.
I will see if I can figure out =numbers=, may need to google some examples unless you have any?
However, an ‘expiry’ will not work well for what we use it for, we want to re-enable the internet for users as soon as they pay, not hours later with an automated update, not when it should just be a simple API function as above.
An address list item can be a duplicate one, so there’s nothing preventing you from having the client’s IP that will soon expire AND a new address list item that is going to expire next month or whatever (and happens to contain the exact IP address, the exact list name, the exact comment and everything…) - both before and after the period, both items are matches against whatever rules are allowing their internet. Once the first one expires, the second item’s presence would ensure the rule will still be matched, in turn ensuring normal uninterrupted operation.
The only reason not to use this approach is if you wish to transfer their unused time for next month, i.e. accumulate it. If you want to do THAT, you can use “set” on the old item, to modify its timeout to be its current one, plus one month or whatever your payment period is.
