Hi Peter and everyone else following, > Am 12.05.2021 um 14:06 schrieb Peter Jeremy via freebsd-net > <freebsd-net@freebsd.org>: > 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.
do you have some spare time and would you be so kind to look at our discussion here: https://github.com/AdguardTeam/AdGuardHome/issues/3015 Andrey from the AdGuard team references this golang issue: https://github.com/golang/go/issues/8329 Which references this FreeBSD issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 What I as a sysadmin can observe is that the test code Andrey gave me binds to *.53 on IPv4 and IPv6 although I start it with `-l 0.0.0.0` which is clearly an IPv4 "any" address. I am not 100% familiar with the API but as I understand you can treat IPv4 as IPv6 via the socket interface by using an IPv4-mapped IPv6 address. So far so good. But then of course you have an AF_INET6 socket and it seems that FreeBSD does not allow setting IPv4 specific options via setsockopt() because it's an IPv6 socket. Correct? Why can you have a single socket on both address families, anyway? IPv4 and IPv6 are as "related" as IP and IPX - if you go dual stack, treat them both separately - no? Any light you can shed on this issue greatly appreciated. Thanks, Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de i...@punkt.de AG Mannheim 108285 Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein
signature.asc
Description: Message signed with OpenPGP