[Dnsmasq-discuss] Announce 2.85rc1 and security warning.
Matthias Andree
matthias.andree at gmx.de
Sat Mar 20 02:18:47 UTC 2021
Am 19.03.21 um 23:20 schrieb Simon Kelley:
> On 17/03/2021 23:53, Matthias Andree wrote:
>> Am 17.03.21 um 22:48 schrieb Simon Kelley:
>>> Please download
>>>
>>> https://thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.85rc1.tar.gz
>>>
>>> and test it thoroughly. Then look at the diff at
>> Simon,
>>
>> thanks for your and Petr's efforts on this.
>>
>> Unfortunately, 2.85rc1 does not compile on FreeBSD 12.2 out of the box.
>>
>>> cc -O2 -pipe -Wall -Wno-unused-function -Wno-unused-parameter
>>> -Wno-unused-value -Wno-unused-variable -DHAVE_LIBIDN2 -DHAVE_DNSSEC
>>> -I/usr/local/include -DLIBICONV_PLUG -fstack-protector-strong
>>> -fno-strict-aliasing -O2 -pipe -Wall -Wno-unused-function
>>> -Wno-unused-parameter -Wno-unused-value -Wno-unused-variable
>>> -DHAVE_LIBIDN2 -DHAVE_DNSSEC -I/usr/local/include -DLIBICONV_PLUG
>>> -fstack-protector-strong -fno-strict-aliasing
>>> -DLOCALEDIR='"/usr/local/share/locale"' -DVERSION='"2.85rc1"'
>>> -I/usr/local/include -I/usr/local/include -I/usr/local/include
>>> -DLIBICONV_PLUG -c network.c
>>> network.c:729:25: error: no member named 'ifr_ifindex' in 'struct ifreq'
>>> serv->ifindex = ifr.ifr_ifindex;
>>> ~~~ ^
>>> 1 error generated.
>> This name isn't defined on FreeBSD, but it does have this:
>>
>> /usr/include/net/if.h:427:#define ifr_index
>> ifr_ifru.ifru_index /* interface index */
>>
>> What would be a good smoke test to see if this works as intended, how do
>> I need to stimulate dnsmasq?
>>
> <this reply addresses Petr's later reply with patch also.>
>
> I can see that wouldn't compile on BSD. At the top of network.c we have
> different code for different platforms to do the reverse (index to name)
> mapping, and the *BSD code just uses if_indextoname(), so using
> if_nametoindex() in this case is fine.
>
> HOWEVER.
>
> 1) The reason that the Linux build doesn't do that is that (at least
> under Linux) if_nametoindex() opens it's own socket to call ioctl() on
> and closes it afterwards, so each lookup costs a socket() and close()
> syscall.
> The linux version of our local function indextoname() takes the socket
> as an argument and is fed a socket which happens to be open for other
> reasons. On BSD it just wraps if_indextoname().
>
> 2) On *BSD this is moot anyway, since the index we're deriving is used
> for binding a UDP socket to an interface, and *BSD doesn't, as far as I
> know, have an equivalent of the SO_BINDTODEVICE linux ioctl, so it's not
> supported. Matthias, you can't test any code, since to do so you'd need
> to bind a server to an interface
>
> server=8.8.8.8 at eth0
>
> and that will just exit with a "not supported" message on *BSD.
>
> I think the best bet here might be to use if_nametoindex(), on non-linux
> builds, so that the expected data is there, even if it's not used
> (principle of least surprise). I'll commit that patch.
>
>
> Matthias, do you know of FreeBSD has gained an equivalent of
> SO_BINDTODEVICE? Last time I looked it didn't, and a quick Google wasn't
> promising, but if it does that would a useful thing to support.
Simon, thank you.
Apparently FreeBSD still has neither SO_BINDTODEVICE nor IP_SENDIF.
https://github.com/freebsd/freebsd-src is a mirror of FreeBSD's source
and has a search function. Nadazero except users in included/imported
third-party application code.
For specifying datagram source addresses, it would appear you can either
bind(2) the socket you send from, or you can use IP_SENDSRCADDR as
ancillary data for sendmsg() if you want to ship out from unbound udp(4)
sockets. Anything else that we need here functionally?
https://www.freebsd.org/cgi/man.cgi?query=ip&apropos=0&sektion=4&manpath=FreeBSD+11.4-RELEASE&arch=default&format=html
https://www.freebsd.org/cgi/man.cgi?query=sendmsg&apropos=0&sektion=2&manpath=FreeBSD+11.4-RELEASE&arch=default&format=html
and the structures are on the recv(2) manpage:
https://www.freebsd.org/cgi/man.cgi?query=recvmsg&apropos=0&sektion=2&manpath=FreeBSD+11.4-RELEASE&arch=default&format=html
More information about the Dnsmasq-discuss
mailing list