Why does my SNMP query just time out with no error?

SNMP doesn't return a "wrong password" message — a bad community string, a blocked port, or a stopped daemon all look identical: silence, then a timeout. Isolate it by querying localhost on the server first. If that works, it's the network or firewall; if it fails, it's the daemon, community, or view.

snmpwalk works locally but not from another machine — why?

The agent and config are fine; the network layer isn't. It's almost always a firewall blocking the SNMP UDP port, or your client targeting the wrong port. Confirm the port in agentAddress matches what the client dials, and open it for the monitoring source.

I get "No Such Object" for one OID but others work — what's wrong?

That OID isn't in the agent's allowlisted view. The agent is healthy — it's deliberately not exposing that subtree. Add a view ... included line for it in snmpd.conf and restart. See the OID allowlist guide.

Names don't resolve but numeric OIDs do — is the agent broken?

No. The agent is answering correctly; your client just doesn't have the relevant MIB files installed, so it can't translate numbers to names. Install the MIBs, or use -On for numeric output — the data is identical either way.

Does an SNMP timeout mean the server is down?

Not necessarily — it could equally be a firewall, wrong port, or stopped daemon. But when the server genuinely crashes, every query times out, and a local monitor can't distinguish or report it. That's why an external checker matters: it catches the real outage that on-host tooling misses.

SNMP Troubleshooting

When SNMP isn't working, the symptom is almost always the same — a query hangs, then times out — but the cause can sit anywhere along the chain from your client to the agent's config. The trick is to stop guessing and walk the path in order: is the daemon even running, is the port reachable, is the community right, is the OID in the agent's view? Nine times out of ten it's one of those four, and each has a distinct fingerprint. This guide is a systematic route through snmpd troubleshooting: the checks to run, the commands that isolate each layer, and how to read what comes back.

Prerequisites

To debug effectively you want access to both ends of the conversation:

The querying client with Net-SNMP tools — snmpget, snmpwalk, snmptranslate. See the Net-SNMP toolkit.
The server running snmpd, ideally with root or sudo so you can check the service, the config, and the logs.
The community string and port you believe are correct — most SNMP timeout problems come down to one of these being wrong.
A sense of which OID you expect to work, e.g. host uptime 1.3.6.1.2.1.25.1.1.0. Testing a known-good OID separates "the agent is broken" from "that OID isn't exposed."
Permission to inspect the firewall on both hosts and any device in between.

If you only have the client side, you can still diagnose reachability and community issues — you just can't fix a config or view problem without getting onto the server.

Step-by-step

Work the layers from the outside in. Each step rules out one cause, so don't skip ahead.

Confirm the daemon is running. On the server:
```
service snmpd status
```
Not "active (running)"? Start it and check /etc/default/snmpd has SNMPDRUN=yes — see configure /etc/default/snmpd. A stopped daemon explains every timeout at once.
Query from the server itself. This removes the network from the equation:
```
snmpget -v2c -c <community> localhost 1.3.6.1.2.1.25.1.1.0
```
Works locally but not remotely? The agent and config are fine — it's a network or firewall problem (go to step 4). Fails even locally? It's the daemon, community, or view (steps 3 and 5).
Check the community string and version. A wrong community produces a silent timeout, not a helpful error — SNMP doesn't distinguish "bad password" from "no answer." Re-read the com2sec line in snmpd.conf and make sure your client uses -v2c and the exact string.
Test reachability and the port. From the client, confirm the UDP port is open. A timed-out remote query with a working local one is nearly always a firewall or a wrong port. Default is UDP 161; if you moved it, target the new one:
```
snmpwalk -v2c -c <community> <host>:<port> 1.3.6.1.2.1.25.1.1.0
```
Open the port for the monitoring source if it's blocked — check both host firewalls and anything in between.
Check the OID is in the agent's view. If uptime works but another OID returns "No Such Object" or an empty walk, that OID simply isn't allowlisted. Add it in snmpd.conf — the OID allowlist guide shows the view ... included line.
Force numeric output to rule out a missing MIB file locally. If names don't resolve but numbers do, the agent is fine and your client just lacks the MIB:
```
snmpwalk -v2c -c <community> -On <host> 1.3.6.1.2.1.25.3.3.1.2
```

That sequence isolates the vast majority of "SNMP not working" cases. The single most useful habit: always test a known-good OID like uptime first. It tells you whether the pipe works before you go blaming a specific metric.

Here's a quick reference mapping symptom to likely cause:

Symptom	Most likely cause	Where to fix
Timeout, local query also fails	Daemon stopped	/etc/default/snmpd → `SNMPDRUN=yes`
Timeout, local query works	Firewall or wrong port	Host firewall / custom port
Timeout, everything else looks right	Wrong community string	`com2sec` in snmpd.conf
"No Such Object" / empty walk on one OID	OID not in view	OID allowlist
Numbers work, names don't	MIB not installed on client	Install MIBs / use `-On`

Configuration example

Many snmpd troubleshooting sessions end at a config that quietly drifted from a known-good baseline. Here's a minimal, correct v2c read-only snmpd.conf to compare yours against:

# /etc/snmp/snmpd.conf — known-good v2c read-only baseline
agentAddress udp:161,udp6:[::1]:161        # is this the port your client targets?

#       sec.name    source    community
com2sec ReadUser    default   <password>   # does this match your client's -c value?

#       group        sec.model  sec.name
group   ReadGroup    v2c        ReadUser

#       view         incl/excl  subtree
view    ReadData     included   .1.3.6.1.2.1.25.1.1.0   # is the OID you query in here?

#       group        context  model  level   prefix  read      write  notify
access  ReadGroup    ""       any    noauth  exact   ReadData  none   none

Three lines cause most failures, and I've flagged them. The agentAddress port must match what your client dials. The com2sec community must match the -c value exactly — this is the silent killer. And the OID you're querying must fall inside a view ... included subtree, or the agent answers as though it doesn't exist. Restart with service snmpd restart after any edit. Full field notes are in the snmpd.conf reference.

Terminal showing a timed-out snmpwalk next to a successful one during snmpd troubleshooting

Verify it works

Once you've made a change, confirm the fix rather than assuming it. Restart and re-run the known-good query:

service snmpd restart
snmpget -v2c -c <community> localhost 1.3.6.1.2.1.25.1.1.0

A TimeTicks value locally means the agent, community, and view are healthy. Then repeat from the client machine across the network to confirm the path and firewall:

snmpwalk -v2c -c <community> <host>:<port> 1.3.6.1.2.1.25.3.3.1.2

Per-CPU load lines coming back means the whole chain is working end to end. If a specific dashboard metric is still missing while uptime succeeds, the issue is scoped to that OID's view entry, not the agent — a much smaller fix. Verifying from both ends, every time, keeps you from declaring victory on a change that only worked locally.

Security note

Debugging tempts people into loosening things "just to test." Don't leave it loose:

Don't widen the view to all to debug. Add the one OID you need; a temporary wide-open view has a way of becoming permanent.
Don't fall back to a default community like public while testing — use your real, random string.
Re-close firewall rules you opened for a test once you're done.
Avoid SNMPv1 as a "does it work at all" fallback; if you must, remember it and v2c send the community in clear text (RFC 1157 / RFC 1901).
Prefer SNMPv3 where the network isn't trusted — it adds authentication and encryption.

The complete hardening checklist lives in the security section and secure the community string.

Next: connect external monitoring

Here's the uncomfortable part of troubleshooting SNMP: the worst outages are the ones where nothing answers because the whole server is down — and a monitor living on that server can't tell you, because it's down too. That's the exact gap external monitoring closes. An independent checker outside your network keeps polling and turns a dead, silent host into an alert instead of a mystery you notice hours later. It's the reasoning behind double durability — a second, independent source beats relying on the box to report its own failure.

ostr.io Monitoring polls your agent from outside and sends real-time email and SMS alerts the moment a value crosses a limit or the host stops responding — so an SNMP timeout caused by a crash reaches you fast. Once the agent answers cleanly, add an SNMP endpoint in ostr.io.

Diagram of an external monitor detecting a silent, crashed server that on-host tools cannot report