What's new

dnsmasq-dhcp no addresses available

Ripshod

Part of the Furniture
Putting this in this forum because I'm running YazDHCP. It may be related, it may not.
Anyone seen this before?
Code:
Jan  4 11:12:22 ripshod dnsmasq-dhcp[2184]: DHCPSOLICIT(br0) 00:03:00:01:04:34:f6:38:9e:9d
Jan  4 11:12:22 ripshod dnsmasq-dhcp[2184]: DHCPREPLY(br0) 00:03:00:01:04:34:f6:38:9e:9d no addresses available
Jan  4 11:12:24 ripshod dnsmasq-dhcp[2184]: DHCPSOLICIT(br0) 00:03:00:01:04:34:f6:38:9e:9d
Jan  4 11:12:24 ripshod dnsmasq-dhcp[2184]: DHCPREPLY(br0) 00:03:00:01:04:34:f6:38:9e:9d no addresses available
Jan  4 11:12:25 ripshod dnsmasq-dhcp[2184]: DHCPSOLICIT(br0) 00:03:00:01:04:00:6e:84:10:e9
Jan  4 11:12:25 ripshod dnsmasq-dhcp[2184]: DHCPREPLY(br0) 00:03:00:01:04:00:6e:84:10:e9 no addresses available
Jan  4 11:12:29 ripshod dnsmasq-dhcp[2184]: DHCPSOLICIT(br0) 00:03:00:01:04:34:f6:38:9e:9d
Jan  4 11:12:29 ripshod dnsmasq-dhcp[2184]: DHCPREPLY(br0) 00:03:00:01:04:34:f6:38:9e:9d no addresses available
Jan  4 11:12:32 ripshod dnsmasq-dhcp[2184]: DHCPSOLICIT(br0) 00:03:00:01:04:00:6e:84:10:e9
Jan  4 11:12:32 ripshod dnsmasq-dhcp[2184]: DHCPREPLY(br0) 00:03:00:01:04:00:6e:84:10:e9 no addresses available
Jan  4 11:12:36 ripshod dnsmasq-dhcp[2184]: DHCPSOLICIT(br0) 00:03:00:01:04:34:f6:38:9e:9d
Jan  4 11:12:36 ripshod dnsmasq-dhcp[2184]: DHCPREPLY(br0) 00:03:00:01:04:34:f6:38:9e:9d no addresses available
Jan  4 11:12:47 ripshod dnsmasq-dhcp[2184]: DHCPSOLICIT(br0) 00:03:00:01:04:00:6e:84:10:e9
Jan  4 11:12:47 ripshod dnsmasq-dhcp[2184]: DHCPREPLY(br0) 00:03:00:01:04:00:6e:84:10:e9 no addresses available
Jan  4 11:12:53 ripshod dnsmasq-dhcp[2184]: DHCPSOLICIT(br0) 00:03:00:01:04:34:f6:38:9e:9d
Jan  4 11:12:53 ripshod dnsmasq-dhcp[2184]: DHCPREPLY(br0) 00:03:00:01:04:34:f6:38:9e:9d no addresses available
Jan  4 11:13:15 ripshod dnsmasq-dhcp[2184]: DHCPSOLICIT(br0) 00:03:00:01:04:00:6e:84:10:e9
Jan  4 11:13:15 ripshod dnsmasq-dhcp[2184]: DHCPREPLY(br0) 00:03:00:01:04:00:6e:84:10:e9 no addresses available
WAN obtains a /56 of which it alocates /64 to LAN devices. How could it run out in less than 24hrs?
Getting ready to reboot but any thoughts?
 
Have a look at /var/lib/misc/dnsmasq.leases.

Are the leases not being released ?

Is the same mac being assigned to multiple leases ?
(Shouldn't be possible !!!)

Might give you pointer to what is going on !!!
 
Follow on:
If you are 'playing' (my favourite word) with dnsmasq and changing/overriding mac addresses you can find that you fill up the dnsmasq.lease file with assignments that are 'old' and 'redundant'.
They will only flush when the lease(s) times out.
At a push you can edit the file or even delete it ... then deal with the consequences.

Additional later Note:
Clients that had a network interface update which results in a different MAC address might not get the intended IP address immediately. This is because the dnsmasq service has provided this IP address to the old MAC address, and will wait until the lease of this address has expired before re-assigning it.

If the lease needs to be removed faster, shut down the dnsmasq service, remove the lease from the dnsmasq.leases file and start the service again.
 
Last edited:
Are the leases not being released ?
I don't think there's an issue there:
Code:
# cat /var/lib/misc/dnsmasq.leases
35504 e0:51:d8:19:e6:38 10.0.0.15 server ff:cb:39:0a:c7:00:02:00:00:ab:11:d8:d2:de:0a:5e:d7:3b:cb
86061 04:00:6e:84:10:e9 10.0.0.3 Gilly-Phone 01:04:00:6e:84:10:e9
78681 00:17:88:49:44:b8 10.0.0.26 0017884944b8 *
66303 04:b8:6a:cb:66:eb 10.0.0.24 EntOS-StreamBox 01:04:b8:6a:cb:66:eb
35468 ec:74:d7:34:1b:ac 10.0.0.9 phone 01:ec:74:d7:34:1b:ac
35467 00:17:9a:2b:07:e3 10.0.0.19 stb2 01:00:17:9a:2b:07:e3
86125 1c:f2:9a:30:47:aa 10.0.0.4 * *
86065 04:34:f6:38:9e:9d 10.0.0.8 * 01:04:34:f6:38:9e:9d
86060 04:cf:4b:e1:ad:3e 10.0.0.16 Gilly-Notebook 01:04:cf:4b:e1:ad:3e
76396 b0:5a:da:dc:8c:2d 10.0.0.18 * 01:b0:5a:da:dc:8c:2d
duid 00:03:00:01:9a:f0:21:68:05:5c
85619 1 wwww:xxxx:yyyy:zzzz::10ac * 00:03:00:01:ec:74:d7:34:1b:ac
86062 3134327015 wwww:xxxx:yyyy:zzzz::150c Gilly-Notebook 00:04:0d:2a:96:9b:f0:9a:6c:cb:ed:b5:2c:3d:df:f3:f0:55
85584 3409513159 wwww:xxxx:yyyy:zzzz::14eb server 00:02:00:00:ab:11:d8:d2:de:0a:5e:d7:3b:cb
85584 1448103320 wwww:xxxx:yyyy:zzzz::1d9e Gilly-Notebook 00:04:0d:2a:96:9b:f0:9a:6c:cb:ed:b5:2c:3d:df:f3:f0:55

If you are 'playing' (my favourite word) with dnsmasq
All I've done is make a filter file for "dnsmasq" under syslog-ng. No way that's messing with things.
The lease is up in the next two hours. We'll see what happens then 🙃
I could reboot but I want to see where this goes.
 
Follow on:
If you are 'playing' (my favourite word) with dnsmasq and changing/overriding mac addresses you can find that you fill up the dnsmasq.lease file with assignments that are 'old' and 'redundant'.
They will only flush when the lease(s) times out.
At a push you can edit the file or even delete it ... then deal with the consequences. :D:D;)
Second follow on:
Just thought that if you have a phone or tablet that uses random macs you can easily fill up the dnsmasq.lease file IF the phone/tablet is reconnected multiple times within the lease time. (i.e. the lease created does not have time to time out.)
 
Sorry cross post.
 
Sorry cross post.
S'alright. All my devices are set to use their true MAC on my home network. The messages I posted above have stopped now (since 10 minutes ago) so lease seems to be up.
 
The router only configures dnsmasq to send RAs for stateless (SLAAC) addresses, not DHCPv6 addresses, at least for the main network. Unless you’ve setup stateful.
 
I don't think there's an issue there:
Code:
# cat /var/lib/misc/dnsmasq.leases
35504 e0:51:d8:19:e6:38 10.0.0.15 server ff:cb:39:0a:c7:00:02:00:00:ab:11:d8:d2:de:0a:5e:d7:3b:cb
86061 04:00:6e:84:10:e9 10.0.0.3 Gilly-Phone 01:04:00:6e:84:10:e9
78681 00:17:88:49:44:b8 10.0.0.26 0017884944b8 *
66303 04:b8:6a:cb:66:eb 10.0.0.24 EntOS-StreamBox 01:04:b8:6a:cb:66:eb
35468 ec:74:d7:34:1b:ac 10.0.0.9 phone 01:ec:74:d7:34:1b:ac
35467 00:17:9a:2b:07:e3 10.0.0.19 stb2 01:00:17:9a:2b:07:e3
86125 1c:f2:9a:30:47:aa 10.0.0.4 * *
86065 04:34:f6:38:9e:9d 10.0.0.8 * 01:04:34:f6:38:9e:9d
86060 04:cf:4b:e1:ad:3e 10.0.0.16 Gilly-Notebook 01:04:cf:4b:e1:ad:3e
76396 b0:5a:da:dc:8c:2d 10.0.0.18 * 01:b0:5a:da:dc:8c:2d
duid 00:03:00:01:9a:f0:21:68:05:5c
85619 1 wwww:xxxx:yyyy:zzzz::10ac * 00:03:00:01:ec:74:d7:34:1b:ac
86062 3134327015 wwww:xxxx:yyyy:zzzz::150c Gilly-Notebook 00:04:0d:2a:96:9b:f0:9a:6c:cb:ed:b5:2c:3d:df:f3:f0:55
85584 3409513159 wwww:xxxx:yyyy:zzzz::14eb server 00:02:00:00:ab:11:d8:d2:de:0a:5e:d7:3b:cb
85584 1448103320 wwww:xxxx:yyyy:zzzz::1d9e Gilly-Notebook 00:04:0d:2a:96:9b:f0:9a:6c:cb:ed:b5:2c:3d:df:f3:f0:55


All I've done is make a filter file for "dnsmasq" under syslog-ng. No way that's messing with things.
The lease is up in the next two hours. We'll see what happens then 🙃
I could reboot but I want to see where this goes.
"All I've done is make a filter file for "dnsmasq" under syslog-ng. No way that's messing with things."

Don't take 'playing' as a perjorative :)

It is the way I think, an internal 'turn of speech' ... if you are changing something you are 'playing' with it !!!

It comes from 'leaving things alone if they are working' ... you would ask if anyone else had been 'playing' if there was a problem !!!

Many long years of 'playing' with computers (UNIX and its many friends mainly with lots & lots of MS OSes on top !!!)

I have a 'built in' rule that I have applied all my working life ....

If you 'play' with it and it breaks it is your responsibility to fix it, no getout clauses or excuses even if not your fault.

'Play' is just the way I speak/think, sorry. !!!
 
Don't take 'playing' as a perjorative
My time to explain. I wasn't trying to excuse my settings, just that the settings I made would not interfere in any way and cause those messages.
The router only configures dnsmasq to send RAs for stateless (SLAAC) addresses, not DHCPv6 addresses, at least for the main network. Unless you’ve setup stateful.
I use the default "stateless".

Everything is running sweet now so alert over. Nothing abnormal in the dnsmasq log, so while I'm watching i'm not going to draw myself into an anxious waiting game.
 
Last edited:
I understood, thought you might have been thinking I was implying you were at fault.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Back
Top