Re: [Dnsmasq-discuss] DHCP from dnsmasq in docker container

[Geert Stappers]

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

Re: [Dnsmasq-discuss] DHCP from dnsmasq in docker container

[Craig Younkins]

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 
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=1
> > 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:  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  scope host lo
> >valid_lft forever preferred_lft forever
> > 10: eth0@if11:  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 * 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.

Re: [Dnsmasq-discuss] DHCP from dnsmasq in docker container

[Simon Kelley]

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=1
> 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:  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  scope host lo
>        valid_lft forever preferred_lft forever
> 10: eth0@if11:  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 * 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

Re: [Dnsmasq-discuss] DHCP from dnsmasq in docker container

[Geert Stappers]

On Thu, Dec 13, 2018 at 09:10:59AM -0500, 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!
> 
> 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=1
> 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:  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 scope host lo
>valid_lft forever preferred_lft forever
> 10: eth0@if11:  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 * 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
> 

Summary in my words:

} pihole is the DNS part of dnsmasq with some extras.
} pihole is got dockerized
} pihole got DHCP server functionality from dnsmasq
} docker version of pihole had/has trouble with DHCP server,
}  their documentation says "host network"


Back to
> Is there a way to make this work without using host networking?

IIRC there wasn't yet a report on this mailinglist saying

   "FYI  dnsmasq (DNS + TFTP + DHCP) works inside docker"


I do hope that such succes will be reported.


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