SNMP timeout with no response: what each cause looks like

snmpget and snmpwalk print Timeout: No Response from 192.0.2.1. when no SNMP reply arrives before the last retry runs out. An agent may have dropped your request, a filter may have dropped it on the way, or nothing on the device listens on UDP 161.

The developer ran snmpget (net-snmp 5.9.4) on 2026-11-11 against a MikroTik RB4011 router on RouterOS 7.25 (192.0.2.1), a Proxmox VE host running net-snmp snmpd (192.0.2.12) and a web smart switch with no SNMP agent (192.0.2.2). The addresses in the output read 192.0.2.x, and <community> and <user> hide the real community and SNMPv3 user name.

• Wrong community
• No SNMP agent
• The ICMP refusal snmpget misses
• Unknown SNMPv3 user
• Wrong SNMPv3 privacy password
• Other causes
• Checklist

Wrong community: RouterOS drops the request

With the right community, the router answers:

$ snmpget -v2c -c <community> 192.0.2.1 sysDescr.0 sysUpTime.0
SNMPv2-MIB::sysDescr.0 = STRING: RouterOS RB4011iGS+5HacQ2HnD 7.25
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (138807700) 16 days, 1:34:37.00
[exit 0]

With a wrong one, snmpget sends two tries of 2 seconds each and gives up:

$ snmpget -v2c -c wrongcommunity -t 2 -r 1 192.0.2.1 sysUpTime.0
Timeout: No Response from 192.0.2.1.
[exit 1]

SNMPv1 and v2c define no error reply for a bad community. The agent drops the request, and you see the same line a firewall or a stopped agent would give you. RouterOS 7.25 doesn’t serve snmpInBadCommunityNames, the counter that would record the drop, or usmStatsUnknownUserNames:

$ snmpget -v2c -c <community> 192.0.2.1 snmpInBadCommunityNames.0 usmStatsUnknownUserNames.0
SNMPv2-MIB::snmpInBadCommunityNames.0 = No Such Object available on this agent at this OID
SNMP-USER-BASED-SM-MIB::usmStatsUnknownUserNames.0 = No Such Object available on this agent at this OID
[exit 0]

From the same machine, a probe script sent one SNMP request with the community public, which the router doesn’t have, over a connected UDP socket, and tried TCP connects to ports 80 and 443. UDP 161 stayed silent for 2 seconds, and both TCP ports refused. A TCP refusal needs something at 192.0.2.1 to answer, so the route works. The agent or a filter in front of it dropped the SNMP request.

No SNMP agent at all: the same timeout

$ snmpget -v2c -c <community> -t 2 -r 1 192.0.2.2 sysUpTime.0   # web smart switch, no SNMP agent
Timeout: No Response from 192.0.2.2.
[exit 1]

The line and the exit code match the RouterOS case, and the cause differs: this web smart switch has no SNMP agent in its firmware. The same probe got this from it:

Check	Result
UDP 161, connected socket	ECONNREFUSED within 1 ms (ICMP port unreachable)
TCP 80	open
TCP 443	open

The switch is up, serves a web UI and has nothing on UDP 161. It sent the refusal within a millisecond, and snmpget still waited 4 seconds before it printed the same line as for the router. Before you blame the community on a small switch, look for an SNMP page in its web UI: some web smart switches have none.

snmpget can’t see the ICMP refusal

A host with no listener on a UDP port answers with an ICMP port unreachable message, unless its own firewall drops the datagram or rate-limits ICMP. Your kernel gets it. By default, Linux and BSD-derived systems such as macOS hand it only to a UDP socket connected to that one address and port, where the next receive fails with ECONNREFUSED. snmpget doesn’t surface the refusal: it waits out its timeout and reports only that no SNMP reply came.

A connected UDP socket sees it. This Python sketch sends one datagram to UDP 161 and waits 2 seconds:

import socket

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.connect(("192.0.2.2", 161))  # connected: ICMP errors from this peer reach the socket
s.settimeout(2)
s.send(b"\x30\x00")            # not a valid SNMP request
try:
    s.recv(1500)
    print("reply")
except ConnectionRefusedError:
    print("refused: nothing listens on UDP 161")
except socket.timeout:
    print("silence: no refusal came back")

The datagram isn’t a valid SNMP request, so a live agent drops it without a reply. Use the sketch to tell “refused” from “not refused” and nothing more. With root rights, nmap -sU -p 161 192.0.2.2 makes the same split: closed means the refusal came back, open|filtered means silence.

After a refusal, the candidates are few: SNMP is off, the device has no agent, the agent listens on another port, or the address belongs to another host. After silence, the rest stay open: a wrong community, an ACL, a firewall, an unknown SNMPv3 user on an agent that doesn’t report it, a wrong privacy password, a slow agent or no host at the address.

Unknown SNMPv3 user: an error on net-snmp, silence on RouterOS

The same request to two agents:

$ snmpget -v3 -l authPriv -u nosuchuser -a SHA -A wrongpass123 -x AES -X wrongpriv123 192.0.2.12 sysUpTime.0
snmpget: Unknown user name
[exit 1]

$ snmpget -v3 -l authPriv -u nosuchuser -a SHA -A wrongpass123 -x AES -X wrongpriv123 192.0.2.1 sysUpTime.0   # RouterOS
Timeout: No Response from 192.0.2.1.
[exit 1]

The net-snmp agent answered with a Report for usmStatsUnknownUserNames, a counter from RFC 3414, and snmpget printed it as Unknown user name. RouterOS 7.25 sent nothing back. On that router a typo in the user name looks the same as a wrong community.

On an agent that serves the USM counters, read them over v2c before and after a failed v3 attempt. snmpwalk -v2c -c <community> 192.0.2.12 1.3.6.1.6.3.15.1.1 returns all six. On the net-snmp host they read:

SNMP-USER-BASED-SM-MIB::usmStatsUnsupportedSecLevels.0 = Counter32: 0
SNMP-USER-BASED-SM-MIB::usmStatsNotInTimeWindows.0 = Counter32: 0
SNMP-USER-BASED-SM-MIB::usmStatsUnknownUserNames.0 = Counter32: 1
SNMP-USER-BASED-SM-MIB::usmStatsUnknownEngineIDs.0 = Counter32: 3
SNMP-USER-BASED-SM-MIB::usmStatsWrongDigests.0 = Counter32: 2
SNMP-USER-BASED-SM-MIB::usmStatsDecryptionErrors.0 = Counter32: 0

If one counter grew between the two reads, its name tells you which check failed. RouterOS 7.25 returns No Such Object for usmStatsUnknownUserNames, so this check doesn’t work there.

Wrong SNMPv3 privacy password: a timeout

In the SNMP Inspector test lab, a net-snmp 5.9.4 agent stayed silent when the user and the auth password were right and the AES-128 privacy password was wrong. With no reply to read, snmpget can only print the timeout, the same line as for a wrong community.

RFC 3414 has the agent check the digest before it decrypts. With both passwords wrong, the net-snmp host reports the auth failure:

$ snmpget -v3 -l authPriv -u <user> -a SHA -A wrongpass123 -x AES -X wrongpriv123 192.0.2.12 sysUpTime.0
snmpget: Authentication failure (incorrect password, community or key)
[exit 1]

Fix authentication first. A timeout at authPriv after the user and auth checks pass points at the privacy protocol, the privacy password or, for AES-192 and AES-256, the key variant. Treat it as a hint until a request succeeds. SNMPv3 authentication failure covers the auth errors.

Other causes of an SNMP timeout

• SNMP turned off. On many devices SNMP stays off until you enable it, and UDP 161 then refuses unless a host firewall drops the datagram.
• An ACL or an allowed-source list on the agent. An agent can accept requests from listed addresses only and drop the rest without a reply. The community can be right and still fail from your laptop. net-snmp takes a source after the community in rocommunity, and RouterOS keeps an addresses list on each community.
• A firewall, a VPN or Wi-Fi client isolation in between. A firewall between VLANs, a host firewall on the device or a guest Wi-Fi that isolates clients can drop UDP 161. Over a VPN, the agent may see a source address from the VPN pool that its allowed list doesn’t include.
• The wrong port. Agents listen on UDP 161 by default. If yours uses another port, add it to the address: snmpget -v2c -c <community> 192.0.2.1:1161 sysUpTime.0.
• The wrong address. A typo, a device that moved, or another box at that address. An address with no host gives silence, and a host without SNMP gives a refusal. Open the address in a browser: the login page shows which box you hit.
• An agent slower than your timeout. net-snmp waits -t seconds per try (1 by default) and retries -r times (5 by default). If small GETs answer and a walk stops halfway with a timeout, lower the bulk size: snmpbulkwalk -Cr5 -v2c -c <community> 192.0.2.1 ifTable.

Checklist: find the cause in order

1. Address and route. ping 192.0.2.1, then ip route get 192.0.2.1 on Linux or route get 192.0.2.1 on macOS to see the interface and gateway your machine picks. On a VPN, make sure the management subnet goes through the tunnel. A failed ping alone proves little: some devices drop ICMP echo.
2. UDP 161: refused or silent. Run the socket test above or nmap -sU -p 161. A refusal means nothing listens there: go to step 3. Silence: go to step 4.
3. The web UI. Try curl -kI https://192.0.2.2/ or open the address in a browser. A web UI plus a refusal on UDP 161 means the device is up and nothing listens there: SNMP is off, absent or on another port. Look for an SNMP page in the web UI.
4. The community from an allowed host. Run the same snmpget from a machine the agent already answers, such as your monitoring server. If it works there, your address is outside the allowed list or a filter on your path drops SNMP. If it fails there too, check the community (case matters) and the allowed list on the device.
5. v2c against v1. snmpget -v1 -c <community> 192.0.2.1 sysUpTime.0. If v1 answers where v2c timed out, the agent speaks v1 only.
6. SNMPv3 in steps. Send a request at -l noAuthNoPriv with your user. A Report for usmStatsUnknownUserNames (snmpget prints Unknown user name) means the agent doesn’t know the user. A Report for usmStatsUnsupportedSecLevels confirms the user exists. Then go to -l authPriv with both passwords: Authentication failure points at the auth password or protocol, and a timeout after a passed user check points at the privacy settings. If each v3 step stays silent, the agent may drop failures without a Report, as RouterOS did.
7. More time. Repeat with -t 5 -r 2. A reply now means a slow agent or a lossy path.

The connection doctor in SNMP Inspector

On iPhone and iPad, SNMP Inspector reports the same silence as “No response after 2s × 2 attempts” and then runs most of this checklist for you. It starts on the phone: the iOS Local Network permission and the network path over Wi-Fi, VPN or cellular. After a timeout it sends one probe over a connected UDP socket and, in parallel, tries a TCP connect to ports 80 and 443 without sending data. A UDP refusal shows as “The device port may be unreachable”, and with a web UI open on 80 or 443 the doctor adds that some web smart switches have no SNMP at all.

On a timeout, the app explains: “A timeout can mean a wrong community, a firewall, an ACL or a stopped agent.” The doctor marks each hint “Likely”, retries a v2c timeout once over v1 with the same community, takes SNMPv3 from engine discovery to privacy, and never reports a timeout as a wrong password. The compatibility page lists the switches and routers the developer checked the app against.

Questions

What does Timeout: No Response from mean in snmpwalk?

No SNMP reply arrived before the retries ran out. net-snmp waits -t seconds per try, 1 by default, and retries -r times, 5 by default. The line names no cause: an agent or a filter dropped the request, or nothing listens on UDP 161.

Does a wrong SNMP community return an error?

No. SNMPv1 and v2c define no error reply for a wrong community. The agent drops the request and snmpget prints Timeout: No Response. RouterOS 7.25 did this in the test on this page.

How do I check if a switch listens on UDP port 161?

Send one datagram from a connected UDP socket. A host with no listener answers with ICMP port unreachable, and the socket reports it as ECONNREFUSED. nmap -sU -p 161 shows the same case as closed. Silence means an agent or a filter took the datagram, or no ICMP message came back.

Why does SNMPv3 time out instead of showing an authentication error?

A wrong privacy password got no reply from the net-snmp 5.9.4 agent in the app's test lab, and RouterOS 7.25 stayed silent for an unknown user. A wrong auth password on net-snmp returns Authentication failure. See SNMPv3 authentication failure.

Why can't my iPhone SNMP app reach the switch?

Check the iOS Local Network permission first: without it, the app can't reach devices on your network. Then check the path: a VPN or a guest Wi-Fi with client isolation can block UDP 161. The connection doctor in SNMP Inspector checks both before it tests SNMP.