Tracking Customer IP Addresses Automatically?

What are you using to automatically keep track of customer IP addresses and tie them to accounts?

[We are using DHCP and Option 82 to keep track of customer addresses and to tie those addresses in to Preseem. This has proven to be exceptionally fickle and unreliable for us; it appears to be as a result of the combination of MikroTik script, batcher, and Sonar’s handling of the information. I think, if Sonar use the MikroTik API to read the DHCP lease list the majority of our problems would go away. If Sonar would associated addresses with inventoried hardware, that would be even better, but not immediately necessary. These changes would likely fix our problems, but I am looking for other configuration options in the meantime or as a better solution.

I am not really interested in running PPPoE at this time for customer tracking, but I would entertain it if more reliable or the only real option.]

We were looking into walled garden configurations, but it is so common for a customer not to have their address correctly assigned that we would constantly have people calling when their account should be in good standing.

Thank you, Chris

Hi Chris,

We have a very similar setup, but are not using Option 82. So far, we are not seeing the issues you describe. In our set up, Sonar writes DHCP assignments that we have created in the Sonar app into our Mikrotik routers acting as DHCP servers. That gives us a definitive relationship between the MAC address and IP address assigned in Sonar to the DHCP server. If a device attempts to connect to our network and request an IP and they are not set up in Sonar first, they are assigned a Penalty Box (I assume the same concept as the walled garden you refer to) IP address. This address is not routed to the Internet, so they won’t have access to any services. Preseem doesn’t really factor into the IP address assignment process, however, it obviously needs accurate information from Sonar to do its tracking. This configuration has been very reliable for us.

@Christopher_Gray We are in the same exact boat. We Option 82 almost everyone and have gone through great lengths to get Option 82 working on non-wireless customers as well (MDUs, office buildings, etc). I would say on a weekly basis, we have some sort of issue that can be traced back to the batcher not doing its job correctly. As a result, either Preseem does not shape, the customer can’t get online, Sonar does not have IP information on them, etc.

I know the API will allow what you are describing. A competing billing/management platform uses the API to do this. That batcher script seems like a bit of a hack to accomplish this.

We need to have the Mikrotik router tell Sonar the IP, not the other way around. I can’t assign an IP in Sonar to a MAC because I don’t know the customer MAC in 90% of our cases. I know the Agent Remote ID and I don’t think I can have Sonar write an IP to an Agent Remote ID and have that get written to a Mikrotik. So, it needs to flow the other way.

Ideally, Sonar uses the API and polls the DHCP server. When an address is written it looks first for a properly formatted MAC in the “Agent Remote ID” field. If it finds a properly formatted MAC there, it tries to match it in inventory. If there is no properly formatted MAC in that field (ie: it’s text or some other type of data) or it can’t make an Inventory match, it then looks at the “Active MAC Address” field and tries again to make a match in Inventory (prioritize Agent Remote ID).

This would allow Sonar to catch both Option 82 addresses as well as non-option 82 addresses that were written by DHCP. The batcher is mostly doing it this way now - but the batcher is a point of failure that tends to fail. Move this to the API where we already have a connection in Sonar to every router.

Chad / Christopher, are you guys able to recreate the situation where you’re saying the batcher fails or found some sort of correlation of when this happens?

I’d highly recommend opening a ticket with support, we’ve got a ton of customers using this successfully. Maybe you’re using the older lease script or a version of Mikrotik that’s a bit more fussy. Support can help with these things.

I have no idea if my batcher lease script is up to date or not. It’s probably 3 years old?? One of the issues with the batcher and the script is you have no idea when it fails. If my batcher (at Digital Ocean) goes offline for whatever reason or stops working, I have no idea until I notice IPs are missing or customers call to complain that speeds are not correct. The batcher needs to be rebooted every month or so to keep it working. Every now and then Digital Ocean does something and it stops but we don’t know… When the script fails, there is no indication that it failed.

When you guys update the script (if you have), that information did not make it down to us. Trying to keep on top of changes in your github repository is tough. Unless we log into the github and look for stuff, we would never know that things have changed or been updated.

It looks like the last changes to the github for the batcher was 3 years ago so I think we have the latest script unless you have moved to a different github site.

Support should be able to help you out then - give 'em a shout:


There are fundamental problems with the DHCP / batcher implementation. I have spent plenty of time with support, and have generally found most problems that I’ve identified are inherent to the implementation, not necessarily bugs. For the purposes of this discussion, I will be referencing MikroTik DHCP servers.

Quick example: if the batcher happens to be offline for any reason, addresses will not be assigned to accounts. This is not something support can help with, it is inherent to the implementation.

[I do not have the same specific problem as Chad having to regularly reboot the batcher, but mine is hosted within our network.] Similar to Chad, if the batcher is somehow offline for any reason, while IP assignments stop getting passed, there is no notification of such failure. Also, there are times when a MikroTik router may not run the scripts correctly. I have a handful of customers with addresses auto assigned from subnets we don’t even use any longer because their address de-assignments didn’t make it through to Sonar at the time.

Here are some example problems and solutions:

Problem: The batcher was offline, and some assignments did not get to Sonar.

  • Current Solution: Manually log into each MikroTik DHCP server and delete all dynamic leases. Then, when renew requests come through, the batcher will assign all of the addresses to accounts. This does not, however, fix any de-assignments that took place during batcher downtime.
  • Fix: Have Sonar use the MikroTik API to pull leases and sync DHCP lists.

Problem: Hardware is not assigned to an account before it gets an address. Sonar receives the DHCP information, but does not store it anywhere. The customer does not get appropriate provisioning, and possibly has their IP blocked.

  • Current Solution: Check the associated DHCP server to find the lease. Manually delete the lease. The server will run the script upon renewal, send the info to the batcher, then send it to Sonar.
  • Fix: Tie IP addresses to inventory items regardless of location or assignment. Provide notifications of an IP assignment to an unassigned inventory item.

Problem: The batcher sends Option 82 information along with a DHCP request. Sonar checks Option 82 only, not the actual MAC. IP Address is assigned as a piggy back to the Option 82 MAC, and is not assigned to the actual device if it exists. This breaks monitoring of devices behind Option 82 injection.

  • Current Solution: Manually assign IP addresses to inventoried items behind Option 82 injection.
  • Fix: Prioritize inventory MAC over Option 82 MAC. Provide notifications of IP assignments that match more than one account if the two mentioned MACs are not associated with the same account.

There are others, but these are the examples that come to mind.

Regarding unassigned addresses, I just checked and I have 8 addresses in my Preseem report that are not tied to an account (that should be). This number changes each day. Only 3 of them are customers, but that is why we can’t turn on walled garden / billing redirection as it would send good paying customers to the wrong place. I will fix these, and in a few days there will be more.

As David pointed out above, manually configuring addresses for each customer or device does work, but it seems to defeat the purpose of an automated system.

Thank you, Chris

1 Like

100% agree with @Christopher_Gray. Batcher is a bandaid fix to a problem that can be solved more elegantly with the Mikrotik API.

I should bring my batcher in house and take one point of failure away. Wonder if I can safely run it on our DNS recursive servers (that’s all they do is recursive for customers)…

Yes, I agree as well about using the MikroTik API, but not necessarily as a substitute for the batcher. The problem with using only the MikroTik API is that it is a pull, not a push, so you can set it on a timer (ex. pull the list every 10 minutes), but that won’t work for the first few seconds a customer connects.

We use PPPoE so we are insulated from most of these problems, but you don’t have to move to PPPoE to use RADIUS with DHCP. MikroTik does support this now (finally) with auto created simple queues for limitation. Although many of those features are still new in MikroTik, so I have heard of some bugs (maybe they have been fixed since).

Jimmy (and Sonar in general),

The new method of DHCP lease deliver to Sonar looks to be a step in a positive direction. I have read the article posted here:; it appears this method of removing the batcher only fixes one problem… the batcher being offline.

All other problems including hardware being assigned to a specific account, option 82 information being favored over actual inventoried MAC, manual lease deletion to get leases pushed to Sonar, manual lease deletion to get leases moved from one account to another, etc.

Please, it is important to address these other problems in a more significant way.

Thank you, Chris