Re: [Dnsmasq-discuss] DHCP, how to ignore the client MAC address?

[MIchael Schleicher]

On 09.01.19 08:14, john doe wrote:

On 1/8/2019 11:31 AM, smicha wrote:

Hi John,

thanks for your reply.

I did some tests with your hints.

On 7.1.2019 17:41, john doe wrote:


Some hints from dnsmasq.conf:

# Give the machine which says its name is "bert" IP address
# 192.168.0.70 and an infinite lease
#dhcp-host=bert,192.168.0.70,infinite


Do not work with my setup, because when we re-deploy a VM, the MAC
address will be autom. changed.
The re-delpoyed VM will than get a different IP as the old vm had before.



I just tested this option  and the behavior described is correct with
dnsmasq 2.76, from the man page:


I have running the version 2.78.


"--dhcp-host=lap,192.168.0.199 tells dnsmasq to always allocate the
machine lap the IP address 192.168.0.199.
Addresses allocated like this are not constrained to be in the range
given by the --dhcp-range option, but they must be in the same subnet as
some valid dhcp-range. For subnets which don't need"


Yes, the config "--dhcp-host=lap,192.168.0.199" is working. The VM with 
the hostname "lap" will get the IP 192.168.0.199.


But, I have the problem, when I have a new VM, a new version of the VM 
"lap" which have a different MAC address.
Than, that new version of VM "lap" get not the 192.168.0.199. They get 
an other IP from the pool.



As long as a client use the hostname ("lap") the same IP will always be
given to that client, the MAC address is not used.



As far as I see, for the "first" IP provisioning that is true -> the 
Hostname is enough.
But, than the "dnsmasq.leases" file have also the MAC address and 
Client-ID values stored, which will be compared an the next DHCP Requests.
If than one of the values are different (MAC, CLIENT-ID) the DHCP-Client 
will get an other IP.


Please see below, a example...




See also (1) for more info on 'dhcp-host'.


1)  http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html



Maybe is it possible to "patch" the code of dnsmasq, where dnsmasq can
ignore the MAC address in the DHCP task?



Possibly, more nolageable dnsmasqer would need to chime in to do that
though! :)
If '--dhcp-host=hostname,IP' is not working for you more info would need
to be provided.




BTW: the VM "lap" does not have set a special "DHCP-Client-Identifier", 
so it use for DHCP-Client-ID the MAC address.



Here some outputs of the dnsmasq.leases file:

# inital DHCP-Request:

1547107342 00:50:56:85:02:fa 192.168.0.199 lap 01:00:50:56:85:02:fa

As you can see, the VM "lap" (MAC 00:50:56:85:02:fa) get the expected IP 
-> so far so good.



Next, I power off the VM "lap" without a DHCP-Release and deploy a copy 
of the VM "lap" which have than an other MAC (00:50:56:85:02:ff) ! -> 
the MAC will always set by the deployment of a new VM version.



Now, I start the new version of the VM "lap" (the old version of the VM 
"lap" is no longer available.


The dnsmasq.leases looks now, like this:
1547116110 00:50:56:85:02:ff 192.168.0.200 lap 01:00:50:56:85:02:ff
1547107342 00:50:56:85:02:fa 192.168.0.199 * 01:00:50:56:85:02:fa


As you see, the VM "lap" have now the IP "192.168.0.200" and not the 
expected IP "192.168.0.199.


Do you have an idea how I can fix that?
I tested different options with "--dhcp-host", but with no luck.

I hope you can help my.

May do you have an hint in which part of the code, I can fake the 
incoming/received "DHCP CLIENT-ID". I think that is one of the key's to 
fix the problem.


As I said before in a prev. mail. The problem is not there, when the 
DHCP-Client sending a uniq DHCP-Client-ID. In Linux that is not the 
problem i can set that, but in Windows I do not have the option to set 
the DHCP-Client-ID ! :-(


Many thanks
Michael






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

Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Sandeep K M]

Hi,

Its a very simple topology, I have tried to recreate the entire setup on a
different test bed. I still see the same issue:

root@Ubuntu4242:~# tail -f /tmp/dnsmasq
Jan  9 01:57:20 dnsmasq-dhcp[2695]: DHCPSOLICIT(eth1)
00:01:00:01:23:c8:76:d7:00:50:56:bd:57:ed
Jan  9 01:57:20 dnsmasq-dhcp[2695]: DHCPADVERTISE(eth1) 2020::18
00:01:00:01:23:c8:76:d7:00:50:56:bd:57:ed
Jan  9 01:58:32 dnsmasq-dhcp[2695]: DHCPSOLICIT(eth1)
00:01:00:01:23:c8:76:d7:00:50:56:bd:57:ed
Jan  9 01:58:32 dnsmasq-dhcp[2695]: DHCPADVERTISE(eth1) 2020::18
00:01:00:01:23:c8:76:d7:00:50:56:bd:57:ed

Attaching the full setup configuration with topology. Any help will be much
appreciated.

If anyone has any working configuration of dhcpv6 dnsmasq setup with a
relay agent, please let me know.

Mine is a simple setup with a host-h1 (ubuntu) acting as a client,
switch-sw1 acting as a relay agent and host-h2 (ubuntu) acting as a dnsmasq
server. With these if anyone provide me a working config that will be of
great help.

Thanks
-Sandeep

On Mon, Jan 7, 2019 at 7:17 PM Geert Stappers 
wrote:

> On Mon, Jan 07, 2019 at 01:09:11PM +0530, Sandeep K M wrote:
> > On Fri, Jan 4, 2019 at 7:32 PM Geert Stappers wrote:
> > > On Fri, Jan 04, 2019 at 05:34:03PM +0530, Sandeep K M wrote:
> > >
> > > > Please let me know if any other information is needed.
> > >
> > > Not yet mentioned in this thread is working connectity between "server"
> > > and "client".  This will require temporary manual configuration
> > > of an IPv6 address at client. Let say it is 2020::2/120.
> > > Then verify with more than "ping". Example given:  `ssh 1040::2`
> > >
> > > It shall reveal how well router ( with the odd name 'Switch' ) is
> > > configured for routing between 1040::/120 and 2020::/120.
> > > Also if the ssh deamon is able to send packets out on the right
> > > interface.
> > >
> > > I do know that it might seem a detour. And we also known that
> > > original poster is already stuck with current setup. So the "detour"
> > > could be a step forward.   Good luck.
> > >
> > >
> > Hi,
> >
> > As you suggested I added the IPv6 address 2020::2/120 manually to my
> client
> >
> > # ip -6 addr add 2020::2/120 dev eth1
> >
> > when I pinged the server it failed :
> >
> > root@Ubuntu3481:~# ping6 -I 2020::2 1040::2
> > PING 1040::2(1040::2) from 2020::2 : 56 data bytes
> > ping: sendmsg: Network is unreachableping: sendmsg: Network is unreachale
> >
> > Then I added a default route:
> >
> >
> > root@Ubuntu3481:~# ip -6 route add default via 2020::1
> > root@Ubuntu3481:~# ip -6 route
> > 2020::/120 dev eth1  proto kernel  metric 256
> > fe80::/64 dev eth0  proto kernel  metric 256
> > fe80::/64 dev eth1  proto kernel  metric 256
> > default via 2020::1 dev eth1  metric 1024
> >
> > I see the ping is working fine now:
> >
> > root@Ubuntu3481:~# ping6 -I 2020::2 1040::2
> > PING 1040::2(1040::2) from 2020::2 : 56 data bytes
> > 64 bytes from 1040::2: icmp_seq=1 ttl=63 time=0.278 ms
> > 64 bytes from 1040::2: icmp_seq=2 ttl=63 time=0.178 ms
> > 64 bytes from 1040::2: icmp_seq=3 ttl=63 time=0.172 ms
>
> So ICMP packets can roundtrip across the router.
> If other packets can, is still unknown.
> (As in '> > Then verify with more than "ping". Example given:  `ssh
> 1040::2`')
>
>
> Idea is finding out if the original problem could be caused
> by incomplete routing rules.
>
>
>
> > But when I remove the manually configured IPv6 address and try to get a
> new
> > IPv6 using "dhclient -6 eth1" again it fails. I see the same log lines in
> > dnsmasq log:
> >
> > Jan  7 07:19:54 dnsmasq-dhcp[3815]: DHCPSOLICIT(m1s1p7)
> 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
> > Jan  7 07:19:54 dnsmasq-dhcp[3815]: DHCPADVERTISE(m1s1p7) 2020::19
> 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
> > Jan  7 07:19:55 dnsmasq-dhcp[3815]: DHCPSOLICIT(m1s1p7)
> 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
> > Jan  7 07:19:55 dnsmasq-dhcp[3815]: DHCPADVERTISE(m1s1p7) 2020::19
> 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
> >
> > When we have enable-ra configured wont dnsmasq advertise the gateway
> IP's ?
> > Do we need to enable RA even in the switch where relay agent is running ?
> > can we configure default gateway to the clients via dhcpv6 options
> similar
> > to IPv4 ?
> >
> >
> > PS: If I replace dnsmasq server with ISC DHCP server everything works
> fine.
>
> And the essential configuration items of the working setup
> are correctly transposed to the non-working setup?
>
>
> Regards
> Geert Stappers
> Curious about why the DHCPADVERTISE packets aren't seen with a network
> sniffer.
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
Topology

+--+---+
| dnsmasq server (Ubuntu)  | 
+--+ 
   | eth1 (1040::2/120)
   | (IP route: 2020::/120 via 1040::1 dev eth1  metric 1024)
   |
   | 

Re: [Dnsmasq-discuss] Patch to cache SRV records - updated version (#3)

[Simon Kelley]

Magic, thank you.

The fix, to a high level of confidence, is

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=a90f09db4cc635941a32b973b57e58c662569625

and the problem involved querying for a SRV record for

_bookmarkdavs._tcp.p48-bookmarks.icloud.com

which returns NXDOMAIN, as it should, but drops a little logic bomb into
the cache datastructures which will detonate some unpredictable time
later, when the cache entry is freed.

Any non-existing SRV record will have the same effect.



I've also seen a tight-loop problem in my testing, which I don't think
is this problem. There's another fix,

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=2896e2485e44c04e73a0b7c9f7cbc9c8515d0800

which I think fixes that, but I'm not 100% sure I can think myself from
the error to the tight loop, so I'm doing some more testing.


Thanks for your contribution with this, and please keep running the
development code. It really helps for people to do that.

Cheers,

Simon.


On 08/01/2019 23:51, Mufasa wrote:
> The requested core dump files have been sent.  I updated my CFLAGS to use -g 
> instead of -O2 and executed the ulimit command immediately before dnsmasq is 
> launched (same script) in the fresh container.
> 
> Because of the default behavior of Ubuntu’s Docker image, core dump files 
> were not being generated nor could I set the core dump output location to a 
> directory instead of the non-functional apport configuration default, so I 
> made these additional changes to my environment to generate the files:
> 
> "docker —run”, the command to launch the container,  got new parameters 
> "--privileged --ulimit core=-1” per recommendations I found on generating 
> core dumps in a container.  This was in addition to running the ulimit 
> command in the shell script I start dnsmasq from.
> 
> The launch script now does this to set the core dump location:
> echo '/tmp/core.%h.%e.%t' > /proc/sys/kernel/core_pattern
> 
> -Daniel
> 
>> On Jan 8, 2019, at 3:14 AM, Simon Kelley  wrote:
>>
>> Thanks for the feedback, and for tracking the bleeding-edge code. The
>> following should help get useful information.
>>
>> 1) Replace -O2 with -g in your compilation flags
>> 2) run the command "ulimit -c unlimited" from the shell you start
>> dnsmasq from.
>>
>> When it goes bang, send me the core dump and the dnsmasq binary.
>>
> 
> ___
> 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] android client does not check ip address with DHCPREQUEST

[Inigo de la Fuente]

Hi All,

I have performed several test and already have opened one thread about this 
issue. I have seen unexpected behavior on android when DHCPv4 client tries to 
reuse a previously allocated network address and this address is unavailable on 
the server.

The test steps are the following:

  1.  Set the range of DHCP leases to only 1. Until now, DHCP can only lease 
one address.
  2.  Connect a device and get the only IPv4 address lease available then 
disconnect.
  3.  On the server dnsmasq leases file, replace the IPv4 lease and give the 
address to other machine.
  4.  Reconnect the device on point 1.


Basically on windows and IOS I can see that the first message on the DHCP 
client-server communication is a DHCPREQUEST sent by the client with the IPV4 
address that wants to reuse. Then, the server respond with a DHCPNAK indicating 
the lease is not available anymore on the server. After that the client tries 
to get a new IPV4 but is not possible because no IPV4 range is available. (the 
only available address is assigned).
This is the correct behavior indicated on RFC1531

However, on Android the DHCPv4 client does not use DHCPREQUEST and then it 
reuses the address even when that address has been reassigned to other machine.

Did someone experience that?

Regards and thanks in advance




 Disclaimer 
This email and any files transmitted may contain proprietary and confidential 
information of ICT Group N.V. or any of its subsidiaries ("ICT") and is 
intended only for the (use of the) named recipient(s) above. If you have 
received this message in error or are not the intended or named recipient(s) of 
this message, please immediately notify the sender by return and delete this 
email message from your computer. Any views or opinions presented are solely 
those of its author and do not necessarily represent those of ICT. You are 
hereby notified that unauthorized disclosure, use, dissemination, forwarding, 
printing or copying of this e-mail and its attachments either whole or partial 
of its contents is strictly prohibited. ICT cannot guarantee that email 
communications are secured and error-free and does not accept any liability for 
damages resulting from the use of email. The general terms and conditions of 
purchase respectively sale and delivery of ICT are applicable to all 
transactions and undertakings resulting therefrom.

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

Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Simon Kelley]

On 04/01/2019 06:25, Sandeep K M wrote:
> Hi Simon,
> 
> Thanks a lot for your prompt reply.
> 
> Attached are the packet captures:
> 
> 1. Packets exchanged between client and relay (client-relay.pcap)
> 2.  Packets exchanged between relay and server (relay-server.pcap)
> 3. strace of dnsmasq (dnsmasq.trace)
> 
> Please let me know if any other information is required.  
> 
> I am not an expert in reading pcap's or strace but I do see in the
> attached strace i.e. dnsmasq.trace file that ""DHCPADVERTISE" message is
> being written to the same interface from which it received the
> "DHCPSOLICIT" packet. But still it is fails to go out of that interface.
> 
> 06:04:09.371741 write(2, "DHCPADVERTISE(m1s1p7) 2020::14
> 00:01:00:01:23:c1:b0:e2:00:50:56:bd:09:fb ", 73) = 73
> 
> Any help on this would be greatly appreciated. Also is there any example
> configuration of dnsmasq dhcpv6 working with relay ? Any reference would
> be of great help.
> 

I'm sure this was tested with a relay, but the current test harnesses
here would take some work to get into a position to test this code, so
I'm going to try and use you as a tester, if that's OK?


Looking at the strace output, dnsmasq logs that it's sending a
DHCPADVERTISE reply, but it never calls sendto() to actually send the
packet. This is definitely a dnsmasq bug, and not something in your
network that's causing the packet to get lost: it never gets sent.


What's confusing me is that manually tracing the code paths from what's
known to be working (log the DHCPADVERTISE) to the sendto() call that
should send that packet, I can't see any reason why the code should fail.

Are you in a position to run dnsmasq under gdb and step through the
relevant code? I can give you detailed instructions on where to set
breakpoints and where the reply packet could be getting lost. The path
is maybe 50 lines.

Staring at the code has found me one bug, but it's not relevant in this
case. (The code to avoid copying an RFC6939 link address option in a
relay request to the reply to the relay actually sends a zero-length
option, instead of eliding it entirely.)

Cheers,

Simon.





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

Re: [Dnsmasq-discuss] android client does not check ip address with DHCPREQUEST

[Simon Kelley]

RFC1531 is twice obsoleted. The current definition of DHCP is RFC2131,
which says, in para 3.2.


  The client times out and retransmits the DHCPREQUEST message if
  the client receives neither a DHCPACK nor a DHCPNAK message.  The
  client retransmits the DHCPREQUEST according to the retransmission
  algorithm in section 4.1.  The client should choose to retransmit
  the DHCPREQUEST enough times to give adequate probability of
  contacting the server without causing the client (and the user of
  that client) to wait overly long before giving up; e.g., a client
  retransmitting as described in section 4.1 might retransmit the
  DHCPREQUEST message four times, for a total delay of 60 seconds,
  before restarting the initialization procedure.  If the client
  receives neither a DHCPACK or a DHCPNAK message after employing
  the retransmission algorithm, the client MAY choose to use the
  previously allocated network address and configuration parameters
  for the remainder of the unexpired lease.  This corresponds to
  moving to BOUND state in the client state transition diagram shown
  in figure 5.


If the Android client took out DHCP lease of length (say) one hour, it's
entitled to use that address for one hour, without ever talking to the
DHCP server again. By editing the lease database, you've misconfigured
dnsmasq and caused it to lease an address to another machine which it
has already leased to the Android phone. If you want to play such games,
you need to use short leases and include delays before reusing the address.


Cheers,

Simon.


On 09/01/2019 15:48, Inigo de la Fuente wrote:
> Hi All,
> 
>  
> 
> I have performed several test and already have opened one thread about
> this issue. I have seen unexpected behavior on android when DHCPv4
> client tries to reuse a previously allocated network address and this
> address is unavailable on the server.
> 
>  
> 
> The test steps are the following:
> 
>  1. Set the range of DHCP leases to only 1. Until now, DHCP can only
> lease one address.
>  2. Connect a device and get the only IPv4 address lease available then
> disconnect.
>  3. On the server dnsmasq leases file, replace the IPv4 lease and give
> the address to other machine.
>  4. Reconnect the device on point 1.
> 
>  
> 
> Basically on windows and IOS I can see that the first message on the
> DHCP client-server communication is a DHCPREQUEST sent by the client
> with the IPV4 address that wants to reuse. Then, the server respond with
> a DHCPNAK indicating the lease is not available anymore on the server.
> After that the client tries to get a new IPV4 but is not possible
> because no IPV4 range is available. (the only available address is
> assigned).
> 
> This is the correct behavior indicated on RFC1531
> 
>  
> 
> However, on Android the DHCPv4 client does not use DHCPREQUEST and then
> it reuses the address even when that address has been reassigned to
> other machine.
> 
>  
> 
> Did someone experience that?
> 
>  
> 
> Regards and thanks in advance
> 
>  
> 
> 
> 
>  Disclaimer 
> This email and any files transmitted may contain proprietary and
> confidential information of ICT Group N.V. or any of its subsidiaries
> (“ICT”) and is intended only for the (use of the) named recipient(s)
> above. If you have received this message in error or are not the
> intended or named recipient(s) of this message, please immediately
> notify the sender by return and delete this email message from your
> computer. Any views or opinions presented are solely those of its author
> and do not necessarily represent those of ICT. You are hereby notified
> that unauthorized disclosure, use, dissemination, forwarding, printing
> or copying of this e-mail and its attachments either whole or partial of
> its contents is strictly prohibited. ICT cannot guarantee that email
> communications are secured and error-free and does not accept any
> liability for damages resulting from the use of email. The general terms
> and conditions of purchase respectively sale and delivery of ICT are
> applicable to all transactions and undertakings resulting therefrom.
> 
> 
> 
> ___
> 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] what do the contents of /var/lib/misc/dnsmasq.leases mean?

[Simon Kelley]

My guess is that the two copies of dnsmasq that are configured to do
DHCP are using the same leases file, which is an all-bets-are-off
situation. Using the --dhcp-leasefile option to give them separate files
will at least give you a chance of making your config work.


Cheers,

Simon.

On 04/01/2019 04:48, Sean Kelly wrote:
> Sure! It's a long story, but perhaps interesting. I got a quad core 2.42
> GHz, 8GB ram 128GB SSD WIFI, dual nic, Thin Mini PC
>  off Amazon that I had
> intended to use as my home router running pfsense. I have really crappy
> DSL at home with an average speed of 1.5Mbps. I have a tablet with 5G
> and "unlimited" data that I can tether through USB that occasionally
> gets deprioritized. (TMobile aint great but it beats everything else) So
> my plan was a router that could switch between DSL and tethered tablet
> and provide a hopefully better home internet environment.
> 
> The device has USB, two nics and wifi. When I went to install pfsense I
> discovered that the wifi and tethered tablet drivers were missing and
> not being a linux kernel guy it sounded like a daunting task to get that
> working. I had a ubuntu desktop live usb stick that I was using to get
> hardware info for the pfsense installation and it seemed to work great.
> So I just installed that. I've only ever used linux in vms as servers so
> this was also an opportunity to learn a new desktop environment. Aside
> from the router, I also have several smart switches
>  and 
> three wireless
> access points
> .
> The router's wifi didn't cover the whole house and amazon echo's
> intercom feature was too cool not to utilize. Long term, I'd like to
> isolate the access points on their own vlan (practice good security etc)
> but that is in the backlog for after I get the basic configuration working.
> 
> So this is where things get interesting. All my linux friends told me I
> should start ripping parts out of my ubuntu distro and just use
> iptables, shorewall, dhcd, etc. I used to work on Windows at Microsoft
> and it didn't make sense to me that Ubuntu developers would not make the
> best choices of technologies when building Ubuntu and all ripping out
> services and swimming upstream would buy me is that opportunity to
> relearn why the Ubuntu developers made the choices they made. So instead
> of fighting the system I would embrace it and learn to use it as best as
> I could. I acknowledge this is cathedral thinking in the bazaar but I
> feel like I'm really close to getting it all working.
> 
> Anyway, when I configure network manager to share my wifi and one of my
> nics, it runs three copies of dnsmasq like so.
> 
> /usr/sbin/dnsmasq
>   --no-resolv
>   --keep-in-foreground
>   --no-hosts
>   --bind-interfaces
>   --pid-file=/var/run/NetworkManager/dnsmasq.pid
>   --listen-address=127.0.1.1
>   --cache-size=0
>   --conf-file=/dev/null
>   --proxy-dnssec
>   --enable-dbus=org.freedesktop.NetworkManager.dnsmasq
>   --conf-dir=/etc/NetworkManager/dnsmasq.d
> 
> /usr/sbin/dnsmasq
>   --conf-file
>   --no-hosts
>   --keep-in-foreground
>   --bind-interfaces
>   --except-interface=lo
>   --clear-on-reload
>   --strict-order
>   --listen-address=192.168.69.1
>   --dhcp-range=192.168.69.10,192.168.69.254,60m
>   --dhcp-option=option:router,192.168.69.1
>   --dhcp-lease-max=50
>   --pid-file=/var/run/nm-dnsmasq-wlp2s0b1.pid
>   --conf-dir=/etc/NetworkManager/dnsmasq-shared.d
> 
> /usr/sbin/dnsmasq
>   --conf-file
>   --no-hosts
>   --keep-in-foreground
>   --bind-interfaces
>   --except-interface=lo
>   --clear-on-reload
>   --strict-order
>   --listen-address=192.168.0.254
>   --dhcp-range=192.168.0.1,192.168.0.245,60m
>   --dhcp-option=option:router,192.168.0.254
>   --dhcp-lease-max=50
>   --pid-file=/var/run/nm-dnsmasq-enp3s0.pid
>   --conf-dir=/etc/NetworkManager/dnsmasq-shared.d
> 
> The first one is for dns and I have a conf file in
> /etc/NetworkManager/dnsmasq.d with the single line
> 
> cache-size=1000
> 
> The next one is for dhcp on my wifi and the last one is for dhcp on my
> nic. Unfortunately they use the same conf-dir
> (/etc/NetworkManager/dnsmasq-shared.d). I currently have one file there
> that looks like this
> 
> #
> # HUBS
> dhcp-host=,192.168.0.10,den-hub
> dhcp-host=,192.168.0.11,master-hub
> dhcp-host=,192.168.0.12,utility-hub
> dhcp-host=,192.168.0.13,gaming-hub
> dhcp-host=,192.168.0.14,pantry-hub
> #
> # WAPS
> dhcp-host=,192.168.0.20,sunroom-wap
> dhcp-host=,192.168.0.21,master-wap
> dhcp-host=,192.168.0.22,gaming-wap
> #
> # SUNROOM DEVICES
> dhcp-host=,192.168.0.30,printer
> dhcp-host=,192.168.0.31,laser
> #
> # DEN DEVICES
> dhcp-host=,192.168.0.253,watchdog
> #
> # MASTER DEVICES
> dhcp-host=,192.168.0.252,keeper,infinite
> dhcp-host=,192.168.0.40,wdtv,infinite
> dhcp-host=,192.168.0.148,kodi,infinite
> #
> #