Thank you Simon for the explanation, that makes sense.

I did try manually adding the LAN IP to the interface visible from within
the container via "ip address add 192.168.1.2/24 dev eth0". That eliminates
the error message, and so I assume an offer was made, but the offer was not
received by the requesting LAN device. I believe the bridged networking
mode caused the kernel to drop the packet somewhere.

An overview of the docker networking modes can be found at [1], and a
better view of the details of bridged networking can be found at [2]. In
docker it's most common to use the default bridged network, and using host
networking is considered poor practice because the lack of isolation.
Looking at the list again, the newer macvlan networking driver may be the
best bet for this situation.

What I should have asked in my original message was "Is there a way to
override this check?" I think manually adding the IP to the interface as
above accomplishes the same thing, meaning I got dnsmasq to send the offer.
Still there is something wrong, but I think the problematic behavior lies
in the details of docker bridged networking mode rather than dnsmasq. I
can't ask for anything more from the dnsmasq community, thank you!

[1] https://docs.docker.com/network/
[2]
https://github.com/docker/labs/blob/master/networking/concepts/05-bridge-networks.md

Craig Younkins


On Sun, Dec 16, 2018 at 5:15 PM Simon Kelley <si...@thekelleys.org.uk>
wrote:

> On 13/12/2018 14:10, Craig Younkins wrote:
> > First, thank you for dnsmasq!
> >
> > I'm among a number of people[1][2][3][4] having trouble using dnsmasq
> > for DHCP when it is running in a docker container. Everyone seems to get
> > "no address range available for DHCP request via eth0" in their log
> > unless they change to host networking mode.
> >
> > The code path for that error message is at [5]. I'm having a little
> > trouble understanding the 'contexts', but I think the problem is that
> > the container is running in bridged networking mode, and thus the
> > interface has an IP address outside the netmask range.
> >
> > Is there a way to make this work without using host networking? Maybe
> > adding the external IP to the container interface? Thank you for any
> > suggestions!
> >
>
>
> I'm not familiar with these docker "networking modes", can you explain
> what they mean?
>
>
> What's happening here is quite straightforward to understand.  A DHCP
> request arrives at an interface which has the IP address 172.17.0.2 and
> netmask 172.17.255.255. Dnsmasq tries to find a dhcp-range from which is
> can allocate an address by looking for a DHCP range which covers the
> same network. Since the only available DHCP range is
> 192.168.1.200,192.168.1.251 and that's not the same network, this fails.
>
>
> Depending on exactly how docker is set up, something equivalent to the
> ISC dhcpd's "shared-network" configuration might be the way to go. This
> is a useful facility which I've considered adding before, essentially,
> is allows you to tell dnsmasq that (in this case) 172.17.0.0/16 and
> 192.168.1.0/24 are both on the same network segment or broadcast domain.
> That would allow dnsmasq to deduce that the request which comes from the
> 172.17.0.0/16 segment can be satisfied by a 192.168.1.0/24 address.
>
> Note that there are other requirements needed to make this work.
> Notably, a DHCP client that gets a 192.168.1.0/24 address has to have
> suitable routing to allow it to route packets to 172.17.0.2, and the
> reverse route is also needed.
>
> To be clear: shared-network doesn't exist in released versions of
> dnsmasq, I'm proposing new code.
>
>
> Cheers,
>
> Simon.
>
>
> > Relevant sample configuration:
> > addn-hosts=/etc/pihole/gravity.list
> > addn-hosts=/etc/pihole/black.list
> > addn-hosts=/etc/pihole/local.list
> > localise-queries
> > no-resolv
> > cache-size=10000
> > log-queries=extra
> > log-facility=/var/log/pihole.log
> > local-ttl=2
> > log-async
> > server=8.8.8.8
> > server=8.8.4.4
> > interface=eth0
> > dhcp-authoritative
> > dhcp-range=192.168.1.200,192.168.1.251,24h
> > dhcp-option=option:router,192.168.1.1
> > dhcp-leasefile=/etc/pihole/dhcp.leases
> > domain=local
> >
> > root@6082bda95199:/# ip a
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> > group default qlen 1000
> >     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> >     inet 127.0.0.1/8 <http://127.0.0.1/8> scope host lo
> >        valid_lft forever preferred_lft forever
> > 10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> > state UP group default
> >     link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
> >     inet *172.17.0.2/16 <http://172.17.0.2/16>* brd 172.17.255.255 scope
> > global eth0
> >        valid_lft forever preferred_lft forever
> >
> > To reproduce, you can run something like what is in [6], then enabling
> > the DHCP server through the non-ssl web interface. `docker exec -it
> > pihole /bin/bash` to get into the container and `tail -f
> > /var/log/pihole.log` for the log.
> >
> > [1] https://github.com/pi-hole/docker-pi-hole/issues/355
> > [2] https://discourse.pi-hole.net/t/dhcp-not-working-docker/12593
> > [3]
> https://discourse.pi-hole.net/t/no-address-range-available-for-dhcp-request-via-eth0/14350
> > [4]
> https://serverfault.com/questions/825497/running-dnsmasq-in-docker-container-on-debian-check-dhcp-ignores-dnsmasq
> > [5]
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/rfc2131.c;h=56dc3d103741baeb68a730f0ce15a10338a2f885;hb=91421cb7575df7bb211dacc30dc7c7c715c38299#l345
> > [6] https://github.com/pi-hole/docker-pi-hole/blob/master/docker_run.sh
> >
> > Craig Younkins
> >
> > _______________________________________________
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to