@usex/mikrotik-mcp 5.1.0 → 5.3.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@usex/mikrotik-mcp",
-  "version": "5.1.0",
+  "version": "5.3.0",
   "description": "MCP server for MikroTik RouterOS — 780+ tools over SSH for firewall, NAT, routing, DHCP, DNS, WireGuard, wireless, QoS and more.",
   "keywords": [
     "ai",
@@ -74,6 +74,7 @@
     "prepublish:security": "npm run security:all",
     "test": "vp test run",
     "test:watch": "vp test",
+    "test:coverage": "vp test --ui --coverage --watch",
     "release": "release-it",
     "test:types": "tsc --noEmit",
     "check": "vp check",
@@ -100,10 +101,12 @@
     "@types/bun": "latest",
     "@types/figlet": "^1.7.0",
     "@types/node": "^26.1.2",
-    "@types/react": "^19.2.17",
-    "@types/react-dom": "^19.2.3",
+    "@types/react": "^19.2.18",
+    "@types/react-dom": "^19.2.4",
     "@types/ssh2": "^1.15.5",
     "@types/update-notifier": "^6.0.8",
+    "@vitest/coverage-v8": "4.1.10",
+    "@vitest/ui": "4.1.10",
     "bunup": "^0.16.32",
     "class-variance-authority": "^0.7.1",
     "clsx": "^2.1.1",
@@ -114,7 +117,7 @@
     "react": "^19.2.8",
     "react-dom": "^19.2.8",
     "recharts": "^3.10.1",
-    "release-it": "^21.0.0",
+    "release-it": "^21.0.1",
     "sonner": "^2.0.7",
     "tailwind-merge": "^3.6.0",
     "tailwindcss": "^4.3.3",

package/prompts/setup-ipsec-site-to-site.md

@@ -47,8 +47,20 @@ identical on both ends):
    accepted from {{peer_address}} on the input chain, and add a NAT _bypass_
    (accept/no-nat) rule so {{local_subnet}}→{{remote_subnet}} traffic is NOT
    masqueraded. Apply firewall edits under `enable_safe_mode`.
-7. **Verify** — `get_ipsec_active_peers` and `get_ipsec_installed_sa` to confirm
-   the tunnel established; `ping` a remote host with src-address in {{local_subnet}}.
+7. **MTU / MSS** — policy-mode IPsec has no interface whose MTU you can lower, so
+   MSS clamping is the _only_ lever, and skipping it is the classic "tunnel is up
+   but large transfers hang" failure. ESP tunnel mode costs ~73 bytes (more with
+   NAT-T/UDP-4500). Add `create_mangle_rule`: `chain=forward`, `protocol=tcp`,
+   `tcp_flags=syn`, `tcp_mss=1400-65535`, `action=change-mss`,
+   `new_mss=clamp-to-pmtu` — or a fixed `new_mss=1360` when the path MTU is known
+   and PMTU discovery is unreliable. Endpoints size their MSS from their own LAN
+   MTU and set DF; without the clamp those packets are dropped in transit and the
+   ICMP "fragmentation needed" is usually filtered, so the sender never learns.
+8. **Verify** — `get_ipsec_active_peers` and `get_ipsec_installed_sa` to confirm
+   the tunnel established; `ping` a remote host with src-address in
+   {{local_subnet}}. Then repeat with size 1400 and `do-not-fragment` — small
+   pings passing while large ones fail means the MSS clamp in step 7 is missing or
+   not matching.
 
 Present the matching parameter set for the remote engineer and the exact tool
 calls before applying. Never echo the pre-shared key back in plaintext beyond

package/prompts/setup-l2tp-ipsec-roadwarrior.md

@@ -33,7 +33,19 @@ Build order:
 4. **Enable the server** — `set_l2tp_server` with `enabled=true`,
    `default_profile=l2tp-profile`, `use_ipsec=required`, and a strong
    `ipsec_secret` (this is the IPsec pre-shared key clients enter).
-   `authentication=mschap2`.
+   `authentication=mschap2`. Also set on the same call:
+   - `max_mtu`/`max_mru` = **1400** (L2TP + IPsec ESP overhead easily exceeds
+     100 bytes; leaving 1450 causes the "connects fine, transfers stall" symptom),
+   - `keepalive_timeout` = **30** — dead client sessions otherwise linger and hold
+     their pool address until the default timeout expires.
+
+   The `change_tcp_mss=yes` set on the profile in step 2 makes MSS follow the
+   negotiated MTU automatically — that is the PPP-family equivalent of a
+   `change-mss` mangle rule, and it is why L2TP does not need one. If clients
+   still stall on large transfers, add the mangle rule anyway
+   (`create_mangle_rule`: `chain=forward`, `protocol=tcp`, `tcp_flags=syn`,
+   `tcp_mss=1400-65535`, `action=change-mss`, `new_mss=clamp-to-pmtu`).
+
 5. **Firewall** — accept UDP 500, UDP 4500, UDP 1701, and IP protocol 50 (ESP)
    on the input chain from the internet; allow the {{vpn_pool}} range to reach the
    LAN/internet in the forward chain as required. Apply under `enable_safe_mode`,

package/prompts/setup-wireguard-tunnel-between-sites.md

@@ -123,11 +123,14 @@ Per side, under Safe Mode (`enable_safe_mode` `device=<name>` → edits → veri
 WireGuard adds ~60 bytes of overhead. Small pings work but large flows (TLS, file
 transfer) stall if MTU is wrong:
 
-- Set the wg interface MTU to **1420** (1412 if the WAN is PPPoE) via
+- Set the wg interface MTU to **1420** (1412 if the WAN is PPPoE, 1280 if the path
+  is unknown/multi-hop — 1280 is the always-safe floor) via
   `update_wireguard_interface`.
-- Clamp TCP MSS on the `forward` chain (`create_filter_rule` mangle
-  `action=change-mss new-mss=clamp-to-pmtu tcp-flags=syn`) or set it per the
-  interface MTU, so TCP sessions negotiate a size that fits.
+- Clamp TCP MSS with `create_mangle_rule` (**not** `create_filter_rule` — only the
+  mangle table has `change-mss`): `chain=forward`, `protocol=tcp`,
+  `tcp_flags=syn`, `tcp_mss=1400-65535`, `action=change-mss`,
+  `new_mss=clamp-to-pmtu`. WireGuard has no per-interface MSS option, so this
+  mangle rule is the only place to fix MSS.
 
 ## 8. Verify end to end
 

package/prompts/setup-wireguard-vpn.md

@@ -42,5 +42,26 @@ Steps:
 5. **Client config** — call `generate_wireguard_client_config` with the server
    public key, {{endpoint}}, the listen port, and the assigned client address, and
    present the resulting `[Interface]/[Peer]` config for the user to import.
+6. **Keepalive** — set `persistent_keepalive` to `25` on every peer
+   (`add_wireguard_peer`/`update_wireguard_peer`) and `client_keepalive=25s` in the
+   generated client config. Roaming clients sit behind NAT; a UDP mapping typically
+   expires after ~30 s of silence, after which the server cannot reach the client
+   until the client speaks first. 25 s keeps the mapping alive.
+7. **MTU / MSS** — the step most WireGuard deployments skip, and the reason a VPN
+   "works" for logins but stalls on file transfers, photo/video uploads and some
+   web pages:
+   - WireGuard adds ~60 bytes. Set the interface MTU to **1420**
+     (`update_wireguard_interface`); use **1412** on a PPPoE WAN, or **1280** when
+     the path is unknown — 1280 always fits.
+   - MTU alone is not enough. Endpoints derive their TCP MSS from _their own_ NIC
+     MTU, so a 1460-byte-MSS session still emits oversized packets with DF set;
+     mid-path routers drop rather than fragment and the ICMP "fragmentation needed"
+     is often filtered — a PMTU black hole. Clamp it with `create_mangle_rule`:
+     `chain=forward`, `protocol=tcp`, `tcp_flags=syn`, `tcp_mss=1400-65535`,
+     `action=change-mss`, `new_mss=clamp-to-pmtu`. WireGuard has no per-interface
+     MSS setting, so mangle is the only place this can be fixed.
+   - Verify: `ping` a host across the tunnel with size 1400 and `do-not-fragment`.
+     Small pings succeeding while this fails is the black-hole signature.
 
-Report the server public key, the peer you added, and the full client config.
+Report the server public key, the peer you added, the MTU/MSS/keepalive values
+applied, and the full client config.

package/schemas/tool-catalog.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "version": "5.1.0",
+  "version": "5.3.0",
   "generated": "by scripts/gen-schemas.ts — do not edit by hand",
   "toolCount": 885,
   "tools": [
@@ -24868,7 +24868,7 @@
         "idempotentHint": true,
         "openWorldHint": false
       },
-      "description": "Autonomously investigate a network problem across all diagnostic dimensions: connectivity (ping), interface state & error counters, routing table & BGP/OSPF neighbors, firewall rules & hit counters, NAT & connection tracking, ARP/DHCP state, DNS resolution, CPU/memory pressure, system logs, and VPN tunnel state. Correlates the evidence to deliver ranked root-cause hypotheses with confidence levels, plain-language explanations, and exact RouterOS fix commands. Pass an IP address, hostname, or symptom description as the target. For hop-by-hop path analysis use `trace_path`; for log-specific investigation use `correlate_events`; for fix commands only use `suggest_fix`.",
+      "description": "Autonomously investigate a network problem across all diagnostic dimensions: connectivity (ping), interface state & error counters, routing table & BGP/OSPF neighbors, firewall rules & hit counters, NAT & connection tracking, ARP/DHCP state, DNS resolution, CPU/memory pressure, system logs, and VPN tunnel state — including the tunnel MTU / TCP-MSS-clamp / WireGuard-keepalive checks that catch a PMTU black hole (tunnel pings fine but large transfers, uploads and some HTTPS hang). Correlates the evidence to deliver ranked root-cause hypotheses with confidence levels, plain-language explanations, and exact RouterOS fix commands. Pass an IP address, hostname, or symptom description as the target. For hop-by-hop path analysis use `trace_path`; for log-specific investigation use `correlate_events`; for fix commands only use `suggest_fix`.",
       "inputSchema": {
         "$schema": "https://json-schema.org/draft/2020-12/schema",
         "type": "object",