[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200816081013.GC16027@belle.intranet.vanheusden.com>
Date: Sun, 16 Aug 2020 10:10:13 +0200
From: folkert <folkert@...heusden.com>
To: netdev@...r.kernel.org
Subject: ping not working
Hi,
This might be slightly off-topic altough it involves Linux, tap-device
and ping.
For fun I'm implementing an IP-stack. To do so I open a tap-device and
use read/write to obtain/send packets. I configured the interface with
IFF_NO_PI to not to get flags/protocol header.
At this point it can answer to ARP requests. If I use arping I see that
it replies to requests. Also by verifying in wireshark of course.
Now the problem is though, that ICMP doesn't work. When pinging, I see
packets coming in and replies going out but for some reasons ping
"doesn't see them". In wireshark everything looks fine:
https://vps001.vanheusden.com/~folkert/myip2.pcap (and
https://vps001.vanheusden.com/~folkert/myip.pcap ).
but if I run ping with strace I see something peculiar:
sendto(3, "\10\0&\354\0\0\0\1\303\3508_\0\0\0\0\10\370\r\0\0\0\0\0\20\21\22\23\24\25\26\27"..., 64, 0, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.3.2")}, 16) = 64
recvmsg(3, {msg_namelen=128}, 0) = -1 EAGAIN (Resource temporarily unavailable)
As you see, the recvmsg (always!) fails with an EAGAIN.
My question now is: how can I debug this? Or is this a common bug (in
implementations of ip stacks)?
Folkert van Heusden
Powered by blists - more mailing lists