[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20220407194238.GB3334152@belle.intranet.vanheusden.com>
Date: Thu, 7 Apr 2022 21:42:38 +0200
From: folkert <folkert@...heusden.com>
To: netdev@...r.kernel.org
Subject: bug while receiving SNMP replies (UDP)?
Hi,
I'm developing my own IP-stack (for fun, nothing serious). It also
features an snmp-agent.
Now something strange is happening when doing an snmpwalk. This does not
happen everywhere (e.g. not all friends with Linux I asked to try it so
could confirm the problem) and not always but quite often. I see it
happening with at least kernel 5.16.0-6-amd64 and
linux-image-4.19.0-17-amd64. Also intel or raspberry pi no difference.
What is happening:
21:02:18 57d/1z root@...er:~ 47s 148 # snmpwalk -c public -v 1 myip.vanheusden.com iso
iso.3.6.1.2.1.1.1.0 = STRING: "MyIP - an IP-stack implemented in C++ running in userspace"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.2.1.4.57850.1
iso.3.6.1.2.1.1.3.0 = Timeticks: (938172) 2:36:21.72
Timeout: No Response from myip.vanheusden.com
So you see that it times-out after 3 snmp 'getnext's.
The strange thing here now is though: if I do tcpdump, I see the replies
come in. If I then strace snmpwalk I see the UDP packets not come in
there (pselect times out). dmesg shows no errors or warnings.
21:02:21.935486 IP 192.168.178.2.55233 > 185.243.112.68.161: GetNextRequest(21) .0.1
21:02:21.943187 IP 185.243.112.68.161 > 192.168.178.2.55233: GetResponse(92) .1.3.6.1.2.1.1.1.0="MyIP - an IP-stack implemented in C++ running in userspace"
21:02:21.943523 IP 192.168.178.2.55233 > 185.243.112.68.161: GetNextRequest(28) .1.3.6.1.2.1.1.1.0
21:02:21.949822 IP 185.243.112.68.161 > 192.168.178.2.55233: GetResponse(44) .1.3.6.1.2.1.1.2.0=.1.3.6.1.2.1.4.57850.1
21:02:21.950183 IP 192.168.178.2.55233 > 185.243.112.68.161: GetNextRequest(28) .1.3.6.1.2.1.1.2.0
21:02:21.957688 IP 185.243.112.68.161 > 192.168.178.2.55233: GetResponse(38) .1.3.6.1.2.1.1.3.0=938172
21:02:21.957956 IP 192.168.178.2.55233 > 185.243.112.68.161: GetNextRequest(28) .1.3.6.1.2.1.1.3.0
21:02:21.965300 IP 185.243.112.68.161 > 192.168.178.2.55233: GetResponse(75) .1.3.6.1.2.1.1.4.0="Folkert van Heusden <mail@...heusden.com>"
21:02:22.958318 IP 192.168.178.2.55233 > 185.243.112.68.161: GetNextRequest(28) .1.3.6.1.2.1.1.3.0
21:02:22.966724 IP 185.243.112.68.161 > 192.168.178.2.55233: GetResponse(75) .1.3.6.1.2.1.1.4.0="Folkert van Heusden <mail@...heusden.com>"
21:02:23.959428 IP 192.168.178.2.55233 > 185.243.112.68.161: GetNextRequest(28) .1.3.6.1.2.1.1.3.0
21:02:23.967058 IP 185.243.112.68.161 > 192.168.178.2.55233: GetResponse(75) .1.3.6.1.2.1.1.4.0="Folkert van Heusden <mail@...heusden.com>"
21:02:24.960165 IP 192.168.178.2.55233 > 185.243.112.68.161: GetNextRequest(28) .1.3.6.1.2.1.1.3.0
21:02:24.969778 IP 185.243.112.68.161 > 192.168.178.2.55233: GetResponse(75) .1.3.6.1.2.1.1.4.0="Folkert van Heusden <mail@...heusden.com>"
21:02:25.961346 IP 192.168.178.2.55233 > 185.243.112.68.161: GetNextRequest(28) .1.3.6.1.2.1.1.3.0
21:02:25.967545 IP 185.243.112.68.161 > 192.168.178.2.55233: GetResponse(75) .1.3.6.1.2.1.1.4.0="Folkert van Heusden <mail@...heusden.com>"
21:02:26.962047 IP 192.168.178.2.55233 > 185.243.112.68.161: GetNextRequest(28) .1.3.6.1.2.1.1.3.0
21:02:26.969202 IP 185.243.112.68.161 > 192.168.178.2.55233: GetResponse(75) .1.3.6.1.2.1.1.4.0="Folkert van Heusden <mail@...heusden.com>"
I thought of a firewall-issue, but I would expect to then either get ALL data
or NONE at all, not a bit. But to be sure I added:
iptables -A INPUT -i $EXTERNAL_I -p udp --dport 161 -j ACCEPT
iptables -A INPUT -i $EXTERNAL_I -p udp --sport 161 -j ACCEPT
iptables -A FORWARD -i $EXTERNAL_I -p udp --dport 161 -j ACCEPT
iptables -A FORWARD -i $EXTERNAL_I -p udp --sport 161 -j ACCEPT
iptables -A FORWARD -o $EXTERNAL_I -p udp --dport 161 -j ACCEPT
iptables -A FORWARD -o $EXTERNAL_I -p udp --sport 161 -j ACCEPT
Things like portnumbers and snmp sequence numbers are correct.
Sometimes it works (I get ~73 lines) but then on a laptop behind this
firewall-system I again get only 3 lines after which it stops again
(that laptop has only policy-accept firewall rules and default debian
kvm/virt-manager rules).
When I trace dropped packets, it looks like they're dropped in
nf_hook_slow+0x8f/0xb0. Maybe NF_DROP or NF_QUEUE returning an error?
Could this be a kernel-issue? And/or any hints to track this further
down?
regards
Powered by blists - more mailing lists