You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to know if we can have the option for assigning a static IP address to a Circuit ID?
In Australia for NBN services dynamic connection type we would an option to use the Circuit ID to assign a IP Address to.
Additionally with the PPOE does it support a wildcard username and password? So it will accept any username and passwords that is presented to the ISPAdmin software
Thanks for opening this, Craig — it helps me scope the work properly.
1 & 2 — static IP per Circuit ID (Option 82)
This is the one I want to tackle first. The plan is to add a circuit_id field to the customer record and have ISPadmin provision it via the RouterOS 7 DHCP matcher facility (/ip/dhcp-server/matcher), which can match on the Option 82 agent circuit ID and hand out an address from a pool.
Before I build any UI around it, I'd like your tech to verify the mechanism by hand on your actual NBN handover: create one matcher keyed on a real circuit ID, confirm the customer gets the intended address, and confirm the exact circuit ID string format you see (NBN AVC ID, port identifier, etc.). If you paste a sample circuit ID value and the working router config into this issue, I'll build the automation to match what actually works in your environment rather than what I assume from the docs.
The payoff is the one you described: swap a modem and nothing needs re-entering — the circuit is the identity, not the MAC.
3 — wildcard PPPoE
Honest answer: not possible in the current design, and I want to be upfront about why. Today the app writes a /ppp secret per customer, so RouterOS authenticates a specific username and password. RouterOS has no native "accept any credentials" mode for PPPoE — the standard approach is to point the router's PPP AAA at a RADIUS server (/ppp aaa use-radius=yes) and have RADIUS accept the session, identifying the customer by the Agent Circuit ID passed as NAS-Port-Id rather than by the credentials.
So wildcard PPPoE means ISPadmin would need to manage a RADIUS backend (most likely writing to a FreeRADIUS database) instead of PPP secrets. That's a substantial new module, not a small feature, and I don't want to promise it lightly.
I'd suggest two separate tracks: get Option 82 working for the DHCP/IPoE path first, since that solves your immediate modem-swap problem, and treat RADIUS as its own discussion once we know how much of your base actually needs PPPoE. Does that ordering work for you?
Activity
MikrotikExe commentedon Aug 20, 2026
Thanks for opening this, Craig — it helps me scope the work properly.
1 & 2 — static IP per Circuit ID (Option 82)
This is the one I want to tackle first. The plan is to add a circuit_id field to the customer record and have ISPadmin provision it via the RouterOS 7 DHCP matcher facility (/ip/dhcp-server/matcher), which can match on the Option 82 agent circuit ID and hand out an address from a pool.
Before I build any UI around it, I'd like your tech to verify the mechanism by hand on your actual NBN handover: create one matcher keyed on a real circuit ID, confirm the customer gets the intended address, and confirm the exact circuit ID string format you see (NBN AVC ID, port identifier, etc.). If you paste a sample circuit ID value and the working router config into this issue, I'll build the automation to match what actually works in your environment rather than what I assume from the docs.
The payoff is the one you described: swap a modem and nothing needs re-entering — the circuit is the identity, not the MAC.
3 — wildcard PPPoE
Honest answer: not possible in the current design, and I want to be upfront about why. Today the app writes a /ppp secret per customer, so RouterOS authenticates a specific username and password. RouterOS has no native "accept any credentials" mode for PPPoE — the standard approach is to point the router's PPP AAA at a RADIUS server (/ppp aaa use-radius=yes) and have RADIUS accept the session, identifying the customer by the Agent Circuit ID passed as NAS-Port-Id rather than by the credentials.
So wildcard PPPoE means ISPadmin would need to manage a RADIUS backend (most likely writing to a FreeRADIUS database) instead of PPP secrets. That's a substantial new module, not a small feature, and I don't want to promise it lightly.
I'd suggest two separate tracks: get Option 82 working for the DHCP/IPoE path first, since that solves your immediate modem-swap problem, and treat RADIUS as its own discussion once we know how much of your base actually needs PPPoE. Does that ordering work for you?
Add Circuit ID field (DHCP Option 82) - stored for reference, see #1
Provision DHCP leases by Option 82 Agent Circuit ID (#1)