[Dnsmasq-discuss] Error returning query result from FreeBSD jail

David Nelson dave at dnel.co.uk
Mon Apr 16 12:18:19 BST 2012


On Monday 16 Apr 2012 01:36:28 Matthias Andree wrote:
> Am 11.04.2012 21:13, schrieb Simon Kelley:
> > On 11/04/12 19:49, Jan Seiffert wrote:
> >> David Nelson schrieb:
> >>> Hi,
> >>> I have been trying to get dnsmasq 2.60.1 working on my FreeNAS
> >>> server
> >>> within a FreeBSD 8.2 jail without any luck.
> >>> 
> >>> Dnsmasq is able to receive requests, resolve them either by the
> >>> local
> >>> hosts file or external dns servers but then it can't reply back to
> >>> the enquirer.
> >>> 
> >>> Running in --no-daemon the logs for a local lookup look like this:
> >>> 
> >>> dnsmasq: started, version 2.60 cachesize 150
> >>> dnsmasq: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP
> >>> DHCPv6 no-Lua TFTP no-conntrack
> >>> dnsmasq: reading /etc/resolv.conf
> >>> dnsmasq: using nameserver 212.23.6.100#53
> >>> dnsmasq: using nameserver 212.23.3.100#53
> >>> dnsmasq: read /etc/hosts - 5 addresses
> >>> dnsmasq: query[A] athena from 192.168.x.104
> >>> dnsmasq: /etc/hosts athena is 192.168.x.6
> >>> dnsmasq: failed to send packet: Invalid argument
> >> 
> >> This is the important line. I guess it's forward.c at 113.
> >> This means that the FreeBSD kernel is refusing to send send the
> >> packet, because he
> >> does not like the call parameters.
> >> The problem is, that sendmsg takes lots of parameters, thanks to this
> >> whole msg
> >> foobar.
> >> You could try to start dnsmask with the OPT_NOWILD option (i think
> >> it's -z) to see if
> >> this code path is generating the bad parameters.
> >> 
> >> But i guess the problem runs a little bit deeper.
> >> All BSD-Kernel are a bit schizophrenic when it comes to sa_len. On the
> >> one hand
> >> they inserted the sa_len field into struct sockaddr{|_in|_in6}, on the
> >> other hand
> >> they are the inventors of the BSD-Socket API which takes some form of
> >> sa_len as
> >> an extra argument on all functions.
> >> And to make matters worse they are a little bit picky. If:
> >> a) the sa_len field is not properly set even when it is not used (but
> >> the socklen_t passed into the API) OR
> >> b) the socklen_t passed into the API is not _exactly_ appropriate for
> >> the AF_FAMILIY
> >> of the fd
> >> you get an EINVAL.
> >> The last point means you get an EINVAL error if you tell the kernel "i
> >> have space for
> >> 16 bytes" (you have "unified" addresses storage), but it is only an
> >> ipv4 socket, so it
> >> expects 4 byte. (when i found this out i was ... dissatisfied.)
> >> 
> >> I think the dnsmasq code is to blame here. First in util.c we have the
> >> sa_len function.
> >> It returns the sa_len field for OS which have it. Instead it should
> >> strictly go by
> >> sa_family, no matter what the OS. And second, i can not find any place
> >> in the 2.60 source
> >> code which actually sets the sa_len field, so it is probably sometimes
> >> mem garbage.
> > 
> > You're greping for the wrong thing: the field is set using the sin_len
> > or sin6_len union elements.
> > 
> > It will be something like this, but if it was the address that was
> > wrong, it would fail when --bind-interfaces is set too, and it doesn't
> > (Dave mailed me off list). There must be something wrong with the
> > parameters sent only when setting the source address, or maybe that's
> > not possible in a jail?
> 
> The jail is a security compartment and doesn't permit, for one, raw
> sockets without further ado, or communication using an address not
> assigned to the jail.
> 
> The FreeBSD man pages are available online, see, for instance:
> 
> http://www.freebsd.org/cgi/man.cgi?query=jail
> 
> or the handbook:
> 
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
> 
> I don't have time to dig deeper right now, but I suspect that this
> explains the "jailed" behaviour -- do I read your paraphrase of Dave's
> mail correctly as "--bind-interfaces fixes this"?
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

iirc there is a sysctl switch allow_raw_sockets which I have enabled, toggling 
this didn't seem to make any difference but --bind-interfaces has "solved" this 
problem for me. 

I raised a thread on the FreeBSD forum asking about this issue and I got a 
response indicating that the lack of the loopback IP 127.0.0.1 might be to 
blame and the responder recommended explicitly assigning listen-address in the 
config, which I guess is pretty much an even more manual alternative to bind-
interfaces.

http://forums.freebsd.org/showthread.php?t=31199

David



More information about the Dnsmasq-discuss mailing list