Diagnostic Tools
Diagnostic Tools puts the three classic network-debug commands — Ping, Traceroute, and NSLookup — directly in the panel. The key feature: ping and traceroute can be issued from the NAS, not from the panel. That matters because a packet from the panel doesn’t follow the same route as a packet from your BNG — when a customer says “my ping is bad”, you want to ping from where their session terminates, not from a different IP entirely.
The page is one of the most-used debug surfaces during support calls. It supports MikroTik directly via the RouterOS API; Cisco and Juniper variants are also implemented for environments running generic-RADIUS NAS (added in v1.0.518–525).
How to get here
Section titled “How to get here”- Sidebar → Diagnostic Tools (wrench icon).
- Direct URL:
/diagnostic-tools. - From a NAS row in NAS / Routers — click the wrench icon → opens the page with that NAS pre-selected via
?nas_id=.
Requires the diagnostics.use permission (or admin). Resellers without the permission do not see the page.
Layout
Section titled “Layout”Three tabs, one per tool:
| Tab | Tool | Default executor |
|---|---|---|
| Ping | Ping / PingStream handler | MikroTik /tool/ping on selected NAS, or panel for public IPs. |
| Traceroute | Traceroute handler | MikroTik /tool/traceroute for private destinations; panel traceroute binary for public IPs. |
| NSLookup | NSLookup handler | Panel side — net.LookupX calls in Go. |
Above the tabs is a NAS selector (filled when the URL includes ?nas_id=, or via the dropdown). When you switch NAS, the tabs remember their per-NAS history.
Ping tab
Section titled “Ping tab”Inputs:
- Target — IP address or hostname. The field is a combined search/input: typing pulls subscriber suggestions via
SearchSubscribersso you can ping by username, full name, phone, or partial IP, and the system resolves the right address. - Packet size — 64 to 64,000 bytes. 64 is the default. Use larger sizes when investigating MTU / fragmentation.
- Count — 1 to 100. 5 is the default. Higher for stability sampling.
- Interval — fixed at 200 ms on MikroTik. That gives 5 pings in ~1 second instead of the 5-second default — much faster feedback during a phone call.
Click Start. Results stream in via Server-Sent Events (the PingStream endpoint) — each ping appears as soon as MikroTik returns it, not at the end. The bottom of the panel shows the standard RTT summary (min/avg/max/jitter) and packet-loss percentage in Windows-like format.
Under the hood, Ping invokes the MikroTik /tool/ping API command. MikroTik returns time values in formats like 301us, 94ms514us, 5ms — the handler parses all three. If the NAS is offline or the API is blocked, the handler falls back to the panel’s local ping binary; the result is labelled so you know which path was used.
Auto-select NAS via URL
Section titled “Auto-select NAS via URL”/diagnostic-tools?nas_id=3 opens the page with NAS ID 3 pre-selected. The NAS list page exposes a per-row wrench icon that links here — one click takes you from “I see this NAS is offline” to “I’m pinging from it”.
Traceroute tab
Section titled “Traceroute tab”Inputs:
- Target — IP or hostname.
- Max hops — default 30.
- Source — toggle between MikroTik (run from selected NAS, useful for tracing the customer-side path) and Panel (run from the API container, useful for upstream-side path).
Results render as a hop table:
| Hop | Address | Loss % | Sent | Avg RTT |
|---|---|---|---|---|
| 1 | 0% | 5 | 1.2 ms | |
| 2 | 192.0.2.1 | 0% | 5 | 4.8 ms |
| … | … | … | … | … |
A hop with * in the address means the router on that hop dropped or filtered the probe — not necessarily a problem, but a sign to dig deeper if loss spikes downstream.
For public IPs (anything outside the private ranges), the panel-side traceroute is forced because MikroTik’s traceroute is single-threaded and slow for transit-side debugging.
NSLookup tab
Section titled “NSLookup tab”Runs from the panel container — DNS lookups don’t care which hop they originate from. Inputs:
- Hostname —
example.com,mail.example.com, etc. - Record type —
A(default),AAAA,CNAME,MX,NS,TXT.
Results show all returned records with TTL. Useful when a customer claims their email “isn’t working” — check their MX, see if they swapped providers.
Cisco / Juniper / Huawei support
Section titled “Cisco / Juniper / Huawei support”For environments using generic-RADIUS NAS (added v1.0.518–525), the diagnostic handler dispatches based on nas_device.vendor:
| Vendor | Ping method | Traceroute method |
|---|---|---|
mikrotik | RouterOS API /tool/ping | RouterOS API /tool/traceroute |
cisco | SSH + ping x.x.x.x repeat N | SSH + traceroute x.x.x.x |
juniper | NETCONF <request><ping> | NETCONF <request><traceroute> |
huawei | SSH + ping -c N | SSH + tracert |
generic | Falls back to panel-side | Falls back to panel-side |
Credentials are taken from the NAS row’s API/CLI fields. If the credentials are wrong or the device unreachable, the handler returns the underlying error in the diagnostic panel rather than silently failing.
Common workflows
Section titled “Common workflows”Customer reports intermittent packet loss
Section titled “Customer reports intermittent packet loss”- Diagnostic Tools → Ping tab → NAS = their PPPoE NAS.
- Target = their IP, count = 100, size = 64. Start.
- Watch the live stream. If loss is visible from the NAS, the problem is between NAS and customer (last-mile).
- If NAS-side ping is clean, run the same ping from the panel. Loss there but not from the NAS = problem is between you and your upstream.
”Where is example.com going? It used to work”
Section titled “”Where is example.com going? It used to work””- NSLookup → hostname =
example.com, type =A. Note current IP. - From a customer’s perspective: Ping tab, target =
example.com, source = NAS. - If ping fails but other public hosts work, do a Traceroute to that host to see where it dies — your provider or theirs.
Reach a NAS-side device without a remote console
Section titled “Reach a NAS-side device without a remote console”- Ping → NAS = the relevant NAS, target = the LAN-side IP (e.g., a CPE management address).
- If reachable from the NAS but not from the panel, the panel doesn’t have a route to that subnet — expected; investigate panel-to-NAS connectivity.
- Use this to confirm a Cudy router or AP is alive before sending CPE commands.
Permissions
Section titled “Permissions”| Permission | What it gates |
|---|---|
diagnostics.use | Open the page and run all three tools. |
The handler additionally checks that the caller has access to the chosen NAS — a reseller without nas.view cannot ping from a NAS that doesn’t belong to them.
Related pages
Section titled “Related pages”- NAS / Routers — pick a NAS and jump straight to diagnostics with
?nas_id=. - Subscribers — subscriber autocomplete in the Ping target field.
- Sessions — live PPPoE sessions you might be diagnosing.
- CPE Devices — confirm a CPE is reachable before sending TR-069 commands.
- Sharing Detection — uses similar NAS-side queries to count connections per subscriber.