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

2018-12-16 Thread 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] Multiple instances of dnsmasq on Debian with systemd

2018-12-16 Thread Simon Kelley
This is obviously a large amount of work, so thanks very much for that.

To make use of it, I need to be able to see as clearly as possible what
is being changed, and why. To that end, I'd much rather have diff files
ten  replacement files, but it's fairly easy to generate those for
myself. Having done that, I get vast amounts of noise where you've fixed
up indentation and end-of-line spaces, which makes seeing the actual
changes very difficult. However, reading carefully, I can see most of
what you describe, but also the reversion of all the changes that have
happened to the files since the Debian stable release.


Could I ask you to do the following?


1) Start with the latest code for the sysV init script, systemd unit and
defaults file. You can get these from the git repo at

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob_plain;f=debian/init;hb=HEAD

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob_plain;f=debian/systemd.service;hb=HEAD

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob_plain;f=debian/default;hb=HEAD


2) Make just the functional changes you've identified: no formatting or
other extraneous changes.

3) Send me context diffs (diff -u) of the changes you've made



Cheers,

Simon.


On 01/12/2018 12:20, M. Buecher wrote:
> Hello Simon,
> 
> on my first tries to start multiple dnsmasq instances on Debian 9
> "Stretch" with systemd I faced several issues and created Debian bug
> report #914305 [1].
> Yesterday I finally managed to spend several hours on the issue and
> found a clean solution for it.
> While preparing the text for the bug report I recognized that you're the
> maintainer of the Debian packages, so I decided to write to the dnsmasq
> mailing list first.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914305
> 
> 
> 
> systemd unit files [2] allow to be used for multiple instances when the
> service unit file name ends with the at symbol (@).
> Then the service can be enabled with an instance name following the at
> symbol, e.g. `systemctl enable dnsmasq@main.service`.
> The instance name is available in an escaped format in variable %i
> (lower case) when the unit file is processed.
> The attached unit file dnsmasq@.service passes the escaped instance name
> to the init.d script (minor changes to the code plus `mv -v
> /lib/systemd/system/dnsmasq.service /lib/systemd/system/dnsmasq@.service`).
> 
> The 2nd attached file is the updated init.d script for dnsmasq.
> It now recognizes the instance name via the second script paramater and
> uses it wherever needed or possible (default file, pid file, resolvconf
> protocol, log entries).
> 
> Additionally three special cases had to be handled when running multiple
> instances of dnsmasq:
> a) The original systemd unit file wants to check the configuration
> before starting the service but does not honor the settings from the
> default file (conf file and dir).
>    Therefore the option checkconfig was added to the init.d script.
>    I don't know if there's a common SysInit V standard name for such a
> function [3].
> b) `mkdir /run/dnsmasq` in the init.d script can fail as unit files are
> run in parallel, so the directory has to be checked again if mkdir failed.
> c) Only one dnsmasq instance should be the dns resolver for the local
> system and should bind to localhost.
>    Therefore revived DNSMASQ_EXCEPT="lo" in the default file (3rd
> attached file).
> 
> Additional changes to the files are typo corrections.
> 
> [2] https://www.freedesktop.org/software/systemd/man/systemd.unit.html
> [3]
> https://www.debian.org/doc/debian-policy/ch-opersys.html#writing-the-scripts
> 
> 
> 
> 
> For testing I installed openresolv and dnsmasq on latest Debian 9
> "Stretch" and created some virtual network interfaces via systemd [4].
> The main dnsmasq instance shall run on the real NIC while special
> instances shall run on the extra virtual NICs (dnsextra*).
> 
> Stopped and disabled the original service from the Debian dnsmasq package:
> `systemctl stop dnsmasq.service`
> `systemctl disable dnsmasq.service`
> `systemctl status dnsmasq.service`
> 
> Prepared dnsmasq systemd unit file for instances by renaming and
> updating it:
> `mv -v /lib/systemd/system/dnsmasq.service
> /lib/systemd/system/dnsmasq@.service`
> 
> As instance enabled systemd unit files have to be used with an instance
> name I decided to name the default dnsmasq instance simply "main".
> Not to break SysInit V compatibility a symbol link was used for the
> "renaming" of the default file.
> `ln -s -T dnsmasq /etc/default/dnsmasq.main`
> (P.S. Other idea would be to default INSTANCE in init.d to 'main' when
> instance name not given.)
> 
> Updated also init.d script and normal default file.
> 
> Then prepared two dnsmasq instances:
> 1. Default file for main instance (/etc/default/dnsmasq.main)
> Changed to DNSMASQ_OPTS="--bind-dynamic --except-interface=dnsextra*"
> This way it will avoid binding to the extra virtual NICs while still
> 

Re: [Dnsmasq-discuss] Validation for malformed DHCP packets in dnsmasq

2018-12-16 Thread Simon Kelley
I can't answer your question about if this has been fixed, as there's
not enough information to identify the problem or trigger the bug.

Can you provide  proof-concept code, or even just packet captures of the
malformed packets that cause problems?

I've confused by the "dhcp to be unresponsive from
the switch for a small amount of time." observation. What's happening
here? Note that dnsmasq can queue DHCPDISCOVER requests whilst is if
doing address-in-use testing. If that's causing the unresponsiveness
then it's expected and there are mitigations in place to avoid DOS. If,
on the other hand, the malformed packets are crashing dnsmasq and some
daemon-framework is restarting it, that's bad, and we'd like to know
about it.



Cheers

Simon.



On 10/12/2018 05:59, P, Sreelakshmi wrote:
> Hi All,
> 
>  
> 
> Does anyone has any update on this?
> 
>  
> 
> Thanks!
> 
>  
> 
> *From:* P, Sreelakshmi
> *Sent:* Friday, December 7, 2018 4:19 PM
> *To:* 'dnsmasq-discuss@lists.thekelleys.org.uk'
> 
> *Subject:* Validation for malformed DHCP packets in dnsmasq
> 
>  
> 
> Hi,
> 
>  
> 
> We are using dnsmasq 2.78. We see that there are some security
> vulnerability w.r.t malformed DHCP packets as explained below.
> 
>  
> 
> *_Problem 1:_*
> 
> A malformed dhcp discover packet can cause dhcp to be unresponsive from
> the switch for a small amount of time.  If this was repeated over time
> an attacker could make the dhcp service unresponsive DOSing the box. 
> 
>  
> 
> It starts out with the malformed discover immediately followed by a dhcp
> decline.  then the client sends another dhcp discover packet.  The
> switch does not respond to this discover. 
> 
> After about two seconds the client tries again and dhcp works as normal. 
> 
>  
> 
> *_Problem 2:_*
> 
> DHCP request with anomaly causing DOS condition
> 
>  
> 
> A Malformed DHCP request causes dhcp server to not respond for a short
> period of time.  The request is modified by reducing the size of the
> data in the mac address field in the dhcp request.
> 
> After the request is sent to the switch the client sends another dhcp
> discover which is not responded to.  After about 1.5 seconds the client
> tries again and the discover is responded to.
> 
>  
> 
> *_Problem 3:_*
> 
> DHCP discover packet with extra byte in hardware address causing DOS of
> DHCP on switch
> 
>  
> 
> If an extra byte is added to the hardware address field in a dhcp
> discover it will cause the DHCP service to become unresponsive for a
> short period of time.  If repeated it could be used as a DOS attack.
> 
>  
> 
> *_Problem 4:_*
> 
> DHCPv6 solicit with anomaly in Identity association length field causing DOS
> 
>  
> 
> When the integer value 65534 is placed in the Identity association
> length field of a dhcpv6 solicit packet the switch enters a DOS state
> for a couple seconds
> 
>  
> 
> *_Problem 5:_*
> 
> DHCPv6 solicit 2 Extra bytes trailing option status code causes DOS
> 
>  
> 
> Sending dhcpv6 solicits with extra bytes trailing the option status code
> causes the switch dhcp server to become temporarily unresponsive.
> 
>  
> 
> In a summary, to overcome this problem, DHCP packet validation has to be
> done. Has any fix related to any of these problems have gone in after 2.78?
> 
>  
> 
> Thanks in Advance!!
> 
>  
> 
> Regards,
> 
> Sree
> 
> 
> ___
> 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

2018-12-16 Thread 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] [PATCH] Re: dhcp-boot & dhcp-reply-delay optional tag fixes

2018-12-16 Thread Simon Kelley
Thanks both for this. Petr's more comprehensive patch is now in my tree.

Cheers,

Simon.





On 15/12/2018 09:43, Kevin Darbyshire-Bryant wrote:
> 
> 
>> On 14 Dec 2018, at 16:10, Petr Mensik  wrote:
>>
>> Hi Kevin et al,
>>
>> sure, your fix is correct one. I just found one more place where tags
>> were required. Your pointer handling is not as hopeless as you are
>> saying. :)
> 
> He he - It’s always good to get a second opinion though :-)  And you spotted 
> another place I missed as well.
> 
>>
>> Sorry for inconvenience caused by my change. I miss some tests that
>> would discover it, have to write them someday soon.
>>
>> Petr
> 
> It seems the openwrt users have a very wide range of use cases and notice 
> stuff ;-)
> 
> Your more complete fix is in openwrt master - thank you.
> 
> 
> 
> Cheers,
> 
> Kevin D-B
> 
> 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> ___
> 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] build failure on master with NO_DHCPv6 and fix....

2018-12-16 Thread Simon Kelley
Patch applied. Thanks.

What we really need is a script that calls make repeatedly whilst
cycling through all the possible combinations of build options.


Cheers,

Simon.



On 10/12/2018 10:34, Kevin Darbyshire-Bryant wrote:
> Hi Simon,
> 
> master has a build error when building without HAVE_DHCPv6
> 
> option.c: In function 'dhcp_context_free':
> option.c:1042:15: error: 'struct dhcp_context' has no member named 
> 'template_interface'
>free(ctx->template_interface);
> 
> Sadly, need to put in a little conditional compilation ifdef'erey
> 
> Simplest patch in the world attached
> 
> 
> 
> Cheers,
> 
> Kevin D-B
> 
> 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> 
> ___
> 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] fix ipv6 ipset bug in master

2018-12-16 Thread Simon Kelley
Ooops. My hand's up for that one. Patch applied. Thanks.


Cheers,

Simon.



On 12/12/2018 12:00, Kevin Darbyshire-Bryant wrote:
> Hi Simon,
> 
> Another one fallen out of the openwrt tree shake :-)
> 
> ipv6 ipset addresses weren’t being set correctly.  patch attached 
> 
> 
> 
> Cheers,
> 
> Kevin D-B
> 
> 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> 
> ___
> 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

2018-12-16 Thread 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