I’m hoping to get more eyes on this. There are a number of issues that prevent most workarounds to a rather simple need.
When a client device requests a lease, return/lookup/access the agent-circuit-id field to push off to CRM.
Here are the problems.
- agent-circtuit-id and agent-remote-id are not exposed as variables in dhcp lease-script. I put in a feature request for this multiple times.
- these fields are also not yet committed when the lease-script is run so ‘find $leaseActIP’ get ‘get value-name=active-circuit-id’ returns null values on dynamic leases. I also put in a request here, some way to extract this data in real-time.
The last remaining workaround is a timed script to look these things up and push the data off. However, this isn’t real-time, can’t be triggered by the lease-script (again, the data isn’t ‘committed’ untile AFTER the lease script and scripts it calls finish).
~~
multiple solutions/wants here
a) simply add the option82 data into the lease-script namespace.
b) allow a lease-script to run after the lease is committed. sort of ‘post-up’ script. At least this would allow a find/get workaround.
The purpose of this is to eliminate ‘redundant’ services. I don’t need a radius server, except for option82 lease assignment. If I can script around this I can keep everything on mikrotik or at least keep the things running when other services are down and make more ‘independant’ sites while getting the benefits of option82, IPs that are sticky to the agent-circuit-id, etc.
Further, exposing this data lets me feed my MQQT with live lease assignments. We use this data for real-time anomoly detection.
~~
a completely different solution is to allow leases based on agent-circuit-id first, then mac address. This is possible in most other DHCP packages. However, I don’t want to have other dependancies. I want this all in mikrotik to reduce points of failure and make each router more self-contained and resilient.