-
Notifications
You must be signed in to change notification settings - Fork 98
Roadmap 4x
High-level overview of what is planned for the 4.x release line. Items are roughly in delivery order; later items are more speculative and may shift based on complexity findings.
Automatic snapshot on load, diff-based save — only changed fields are sent to the router. No-op saves skip the API call entirely. Available now on the 4.x branch. See Change tracking.
A new high-level entry point that wraps the existing connection and entity layers behind a clean, async-first interface:
await using var link = await TikLink.ConnectAsync("192.168.1.1", "admin", "pwd");
var rules = await link.Ip.Firewall.Filter
.Where(r => r.Chain == "input")
.ToListAsync();
var rule = await link.Ip.Firewall.Filter.GetAsync("*1");
rule.Comment = "WAN";
await link.SaveAsync(rule); // uses change trackingAll operations are async/await. The existing synchronous ITikConnection API remains fully supported.
The TikLink object exposes a typed tree that mirrors the MikroTik CLI hierarchy — link.Ip.Firewall.Filter, link.System.Identity, link.Interface, etc. — instead of requiring a generic Query<T>() call.
Note: The tree will initially be hand-written for the most common paths (~50). Automatic generation from
[TikEntity]attributes via a Roslyn source generator is planned as a follow-up step — we need to explore the complexity first.
First-class wrappers for non-CRUD commands with fluent builders:
await link.System.Reboot.ExecuteAsync();
await foreach (var ping in link.Tool.Ping
.Address("8.8.8.8").Count(5).ExecuteAsync(ct))
{
Console.WriteLine(ping.Time);
}Bulk sync of a local list against the router, including support for ordered entities (firewall rules, queue trees). Computes the minimal set of add / update / delete / move operations needed to bring the router to the desired state.
Support for the RouterOS 7.1+ HTTP REST API as an alternative transport behind the same TikLink / ITikConnection interface.
Note: We will first explore how well REST maps to the existing sentence-based model and what capability gaps exist (no
/listen, limited streaming) before committing to a full implementation.
IServiceCollection extension for ASP.NET Core / generic host applications:
services.AddTikLink(opt => {
opt.Host = config["MikroTik:Host"];
opt.User = config["MikroTik:User"];
opt.Password = config["MikroTik:Password"];
});Scoped lifetime (DbContext-style). Connection pooling TBD.
Drop legacy targets (net35 / net40 / netcoreapp1.x are already gone as of 3.6). For 4.x we plan to target net6.0 / net8.0 + netstandard2.0 / netstandard2.1, and enable #nullable reference types across the codebase.
.NET Framework 4.8 remains fully supported via netstandard2.0 and will continue to be tested.
Layer-2 communication with a router that has no IP connectivity — useful for recovery and bootstrap scenarios. Ships as part of the core tik4net package (no additional NuGet required).
TikConnectionType.MacTelnet — UDP port 20561, EC-SRP5 authentication, VT100 terminal session driven by the shared CLI layer. MNDP-based MAC discovery built in. See MAC-Telnet-connection.
Encrypted CLI over the WinBox channel (TCP port 8291) — the same port the WinBox application uses. Drives the RouterOS CLI through the WinBox mepty terminal handler, so all CRUD works through the shared CLI layer. Ships as part of the core tik4net package (no additional NuGet required).
TikConnectionType.WinboxCli — EC-SRP5 authentication + AES-128-CBC encrypted session (legacy MD5 fallback for pre-6.43 firmware). Fully encrypted end to end without enabling API-SSL / certificates. See WinBox-CLI-connection.
This is the terminal-driven WinBox mode. Native-M2 (non-terminal structured CRUD) has since shipped — see the WinBox Native sections below.
The same encrypted WinBox terminal CLI as above, but tunnelled over the MAC layer (UDP port 20561, client_type=0x0f90) — so it works without an IP route to the router, combining MAC-Telnet's reach with WinBox's encryption. Ships in the core tik4net package.
TikConnectionType.WinboxCliMac — the full WinBox protocol (EC-SRP5 handshake + chunked AES frames) carried over the proven MAC-layer reliable stream, sharing the same CLI engine as the TCP transport. MNDP-based MAC discovery built in. See WinBox-CLI-MAC-connection.
Structured CRUD over the encrypted WinBox channel (TCP port 8291) using the native M2 protocol — no terminal, no CLI screen-scraping. getall / get / set / add / remove / move map directly to the native handlers, with the API ↔ M2 field mapping reconstructed from the router's version-matched .jg catalog. Reports Crud | Listen | SafeMode. Ships in the core tik4net package.
TikConnectionType.WinboxNative — same EC-SRP5 + AES channel as WinBox CLI, structured M2 above it. See WinBox-Native-connection.
The same structured native-M2 CRUD as above, but carried over the MAC layer (UDP port 20561, client_type=0x0f90) — so it works without an IP route to the router. Implemented by swapping the M2 channel to the MAC-layer session; the entire native engine (.jg resolver, encode/decode, streaming monitors, Safe Mode) is shared with the TCP transport. Ships in the core tik4net package.
TikConnectionType.WinboxNativeMac — MNDP-based MAC discovery built in (RouterMac bypasses it). See WinBox-Native-MAC-connection.
Connecting via SSH and parsing CLI output. Attractive because SSH is universally available, but the plain-text output format is fragile and hard to map reliably to the structured sentence model.
We will prototype this to see whether the approach is viable before including it in the roadmap proper.
MikroTik increasingly uses property values that typed enums cannot represent: negations (!dynamic), comma-separated combinations, version-dependent strings. A TikValue wrapper struct could expose these naturally while staying implicit-convertible from string.
This would be a breaking change to the entity model. We will evaluate scope and migration cost before committing.