# Keenetic Troubleshoot

> Use when someone reports the internet is down, Wi-Fi is bad, a device cannot connect, or the network is slow on a Keenetic router - an ordered playbook that narrows the fault instead of guessing

- **Type:** Skill
- **Install:** `agentstack add skill-salatmaster-keenetic-mcp-keenetic-troubleshoot`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [salatmaster](https://agentstack.voostack.com/s/salatmaster)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [salatmaster](https://github.com/salatmaster)
- **Source:** https://github.com/salatmaster/keenetic-mcp/tree/main/plugins/keenetic/skills/keenetic-troubleshoot
- **Website:** https://www.npmjs.com/package/keenetic-mcp

## Install

```sh
agentstack add skill-salatmaster-keenetic-mcp-keenetic-troubleshoot
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Working out what is wrong with the network

Start from the symptom and work outward. Each step below either finds the fault
or rules out a whole class of them, so do not skip ahead.

## "The internet is down"

**1. Is it the internet or the router?**

```
get_internet_status
```

The flags separate the cases:

- `internet: false`, `gatewayAccessible: false` - the link to the provider is
  down. Go to step 2.
- `gatewayAccessible: true`, `dnsAccessible: false` - the connection is up and
  DNS is the problem. Go to step 3.
- `captiveAccessible: false` on a hotel or public uplink - a captive portal is
  intercepting traffic.
- everything true - the router is fine and the problem is on one device. Go to
  the device section.

**2. The uplink itself**

```
list_interfaces { "kind": "wan" }
```

`link: "down"` means no signal on the physical port: cable, provider, or modem.
`link: "up"` with `state: "down"` means the interface is administratively
disabled, which someone or something turned off.

Check which link actually carries traffic:

```
list_routes { "kind": "default" }
```

If the default route points at a VPN tunnel rather than the physical WAN, and
that tunnel is down, the internet is unreachable even though the provider is
fine. That is a common cause and easy to miss.

**3. DNS**

```
rci_call { "method": "GET", "path": "show/dns-proxy" }
```

Then confirm the tunnel or upstream the DNS traffic depends on is actually up
with `list_interfaces { "kind": "vpn" }`.

## "One device cannot get online"

```
get_device { "mac": "..." }
```

Read in this order:

- `blocked: true` - access is denied for it. That is the answer.
- `schedule` set - it may be outside its allowed hours.
- `policy` set - it leaves through a specific link. Check that link is up with
  `list_interfaces { "kind": "vpn" }`.
- `active: false` - the router has not seen it recently. This is a connectivity
  problem between the device and the router, not a policy problem.

## "Wi-Fi is bad"

```
get_wifi_status
```

Then look at signal strength per device:

```
list_devices { "filter": "wireless", "sort": "rssi" }
```

Reading `rssi`, which is negative and closer to zero is better:

- above -60: good
- -60 to -70: usable
- below -70: expect drops and low speed; the device is too far from the access
  point or something is in the way

If a device is on the 2.4 GHz radio with a strong signal but poor speed, the
band is congested rather than weak. If several devices sit below -70, that is a
coverage problem no setting will fix.

## "The network is slow"

**Who is using it:**

```
list_devices { "sort": "traffic", "limit": 10 }
```

`rxBytes` and `txBytes` are totals since the device was first seen, not a
current rate, so a large number can simply mean it has been connected a long
time. Compare against `active` and treat it as a hint, not proof.

**Is the router itself struggling:**

```
get_system_info
```

`cpuLoad` steadily high, or `connectionsFree` small relative to
`connectionsTotal`, points at the router being the bottleneck. A nearly full
connection table usually means one device is opening huge numbers of
connections, which is worth chasing.

## "Something changed and now it does not work"

```
get_config_state
```

This reports when the configuration last changed, which user did it, through
which interface, and whether there are unsaved changes. If `unsavedChanges` is
true, a reboot returns the router to its last saved state, which is the fastest
way back if a recent change is the cause.

## Before changing anything

Read [keenetic-safe-changes](../keenetic-safe-changes/SKILL.md). Diagnosis is
read-only; the moment you want to fix something, the rules there apply.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [salatmaster](https://github.com/salatmaster)
- **Source:** [salatmaster/keenetic-mcp](https://github.com/salatmaster/keenetic-mcp)
- **License:** MIT
- **Homepage:** https://www.npmjs.com/package/keenetic-mcp

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-salatmaster-keenetic-mcp-keenetic-troubleshoot
- Seller: https://agentstack.voostack.com/s/salatmaster
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.