Date: Wed, 12 May 2021 22:06:09 +1000 From: Peter Jeremy <peter@rulingia.com> To: "Patrick M. Hausen" <hausen@punkt.de> Cc: freebsd-net@freebsd.org Subject: Re: sender source IP address on UDP socket bound to INADDR_ANY in golang Message-ID: <YJvEsc9MED9rOFBV@server.rulingia.com> In-Reply-To: <846FFF4A-0D81-4F04-8358-1B14F996C0A2@punkt.de> References: <2B26D5AB-0F77-4E36-AD9A-D7D6CE5F173C@punkt.de> <YJpenW9tB7LzlyS9@server.rulingia.com> <846FFF4A-0D81-4F04-8358-1B14F996C0A2@punkt.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--B9JC0CRfskJyn7wx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-May-11 13:40:44 +0200, "Patrick M. Hausen" <hausen@punkt.de> wrote: >> Am 11.05.2021 um 12:38 schrieb Peter Jeremy <peter@rulingia.com>: >>=20 >> On 2021-May-08 19:05:56 +0200, "Patrick M. Hausen" <hausen@punkt.de> wro= te: >>> I am facing a problem that is perfectly explained by the semantics >>> of the socket interface for UDP, if one assumes that the application >>> in question binds to INADDR_ANY and does not specifically set the >>> sender address when sending datagrams. >> ... >>> Their code in question is here: >>> https://github.com/AdguardTeam/dnsproxy/blob/1163404e605c3dfbeab360fc35= 40fc290f61a321/proxyutil/udp_unix.go#L47 >>=20 >> So, they say that they retrieve "the net interface IP the packet was >> sent to (dst addr) from the socket's OOB data" and I agree that's what >> the referenced code does. I hadn't heard of that behaviour before and >> went digging... > >Thank you. I received some code with internal debugging added from the >AdGuard core team and will try that today or tomorrow. If I read the quote >from the documentation correctly, on possible explanation would be them >calling recvmsg() but forgetting to setsockopt()? As I see it, the possibilities boil down to: 1) The Go code isn't enabling IPPROTO_IP.IP_RECVDSTADDR on the socket. 2) There's a FreeBSD kernel bug that mean setting IP_RECVDSTADDR isn't being correctly reflected into the recvmsg control message. 3) The control message isn't being correctly plumbed through from recvmsg(2) to the Go RecvMsg() return. Note that a lot of the relevant Go library code is BSD- or FreeBSD- specific so it's also possible that there is a bug in the Go library code. --=20 Peter Jeremy --B9JC0CRfskJyn7wx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmCbxKtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzSPkhAAkjvAzewX4sAjnJSyGiv3OBBa1vePD4dRdyaoSrGk8maD2B5tHkIjkV0m ZArhcgiyuadHDnmHc1f4SahgvCxQ7jw9sO8oihh3P2bYw239JxqsWImZ6HkgTs6q +T/VkGYkNWDivbqAyZv6XdUCoz3akxbr1w01wTgatE3BDRvXK0YDokXafAc+4XGq 4P5TG1p76PVhyBLvZHDwTQ78WvP9oBy9wc+da2J+zhscOv6WM34sEHT50q0SrBBu pjlju8kqsMWctQq2+8krSfmJi2Pfxg5KSx3CEwPau7IAqWnlX9WdRJAVAwnoUGkq DGYcwUJeVDhOe/yyqSoirFdcyRLP3TwheoMr0xic7TMfK1SsA3oOBsi21gszXxhE wEE0mRWWzXXWZveqGDc1hRqxwModVXcb1qTV+137bJzfw4jF9gYz0Mdy7i4qfqdy jocVCH/iCeSoSNmH75wCohd9LnksDTLKb+KXBRMaWlVf++9qvqHO7w7oj+s6zvJf 7e6bhwXrPVqFUA+3mhaJW9lTkX0oPhM0r6BQ6tY1x4UpXn7i3EA0zt8hWfUbn1Qw ySnV3quqy3inctDezuV9ThkHmTna6I5EL+3u4i3Ducp+5mJNN1yQoV86UWON+xy/ zpoCpk2Z83cWcuaV9wIgkIkG726zro4y3BXgmC1Dkgg4jtAVzP4= =AbdL -----END PGP SIGNATURE----- --B9JC0CRfskJyn7wx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YJvEsc9MED9rOFBV>