On Sun, Dec 16, 2018 at 09:19:16PM -0500, Craig Younkins wrote:
> On Sun, Dec 16, 2018 at 5:15 PM Simon Kelley wrote:
> > On 13/12/2018 14:10, Craig Younkins wrote:
> > > First, thank you for dnsmasq!
> > >
> > > I'm among a number of people 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.
> >
> >
>
>
> 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.

A test with docker "macvlan networking" learn me that the docker macvlan
is not plain macvlan from Linux kernel[6]. Largest difference is that
dockerd does DHCP server for its container. Some beware when doing
DHCP server inside container connect with "macvlan". I do now understand
better why  pihole docker recommends "host networking".


> 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!

Please report your milage.


> [1] https://docs.docker.com/network/
> [2] 
> https://github.com/docker/labs/blob/master/networking/concepts/05-bridge-networks.md
> [5] 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/rfc2131.c;h=56dc3d103741baeb68a730f0ce15a10338a2f885;hb=91421cb7575df7bb211dacc30dc7c7c715c38299#l345
> 
[6] https://en.wikipedia.org/wiki/TUN/TAP#External_links go to 
http://www.pocketnix.org/posts/Linux%20Networking:%20MAC%20VLANs%20and%20Virtual%20Ethernets


Groeten
Geert Stappers
-- 
Leven en laten leven

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to