Is your WAP by any chance a router and you have not disabled the DHCP server in it?

The WAP is strictly an access point but the issue is occurring with some wired systems as well. This is a new issue in the last month but none of the hardware has changed in that time.

First of all note that I'm not brilliant with VLANS.

Can you post the output to:

ifconfig | grep ^e -A 1

cat /etc/dnsmasq.d/dhcp.conf

Here's the output:

# ifconfig | grep ^e -A 1
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.132.1 netmask 255.255.255.0 broadcast 192.168.132.255
--
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::b8a7:cdff:feca:d118 prefixlen 64 scopeid 0x20<link>
--
eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::3893:47ff:fe06:a212 prefixlen 64 scopeid 0x20<link>
--
eth0.10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.130.1 netmask 255.255.255.0 broadcast 192.168.130.255
--
eth0.20: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.131.1 netmask 255.255.255.0 broadcast 192.168.131.255
# cat /etc/dnsmasq.d/dhcp.conf
dhcp-option=eth0,1,255.255.255.0
dhcp-option=eth0,28,192.168.130.255
dhcp-option=eth0,3,192.168.130.1
dhcp-option=eth0,6,192.168.130.1
dhcp-option=eth0.10,1,255.255.255.0
dhcp-option=eth0.10,28,192.168.130.255
dhcp-option=eth0.10,3,192.168.130.1
dhcp-option=eth0.10,6,192.168.130.3
dhcp-option=eth0.20,1,255.255.255.0
dhcp-option=eth0.20,28,192.168.131.255
dhcp-option=eth0.20,3,192.168.131.1
dhcp-option=eth0.20,6,192.168.131.1
dhcp-option=eth1,1,255.255.255.0
dhcp-option=eth1,28,192.168.130.255
dhcp-option=eth1,3,192.168.130.1
dhcp-option=eth1,6,192.168.130.1
dhcp-range=eth0,192.168.130.100,192.168.130.254,12h
dhcp-range=eth0.10,192.168.130.100,192.168.130.229,1h
dhcp-range=eth0.20,192.168.131.100,192.168.131.229,1h
dhcp-range=eth1,192.168.130.100,192.168.130.254,12h

To me that looks dodgy. You have eth0 and eth0.10 on different IP/subnet and both have the DHCP server configured. eth0 is configured to hand out addresses in the range 192.168.130.100-192.168.130.254 and I am not sure how this is possible in the webconfig. It is the DHCP server which is probably responding rather than eth0.10 which uses a more limited IP range.

eth1 also seems to be configured to hand out IP addresses by DHCP in the same range as eth0 but is not set up with an IPv4 IP address

I'm afraid your set up has blown my mind and I struggle to understand.

You're right, it's even more confusing now.

I only used the webconfig to set up the server but you're right, since both eth1 and eth0 aren't in use they're both listed as "Invalid" in the DHCP settings. I've never set up DHCP on them so I'm not sure where those entries came from.

Can I safely delete the DHCP ranges/entries for eth1 and eth0 without messing up my nice vlans?

I would suggest you can safely delete them. If the worst comes to the worst you can always copy back in to the file what you've posted to the forum.

yuk... as Nick pointed out the below is totally wrong (amongst other problems) - trying to assign dhcp addresses outside the subnet
Have to assume you did a copy-and-paste and this is not a typo

... snipped

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet 192.168.132.1 netmask 255.255.255.0 broadcast 192.168.132.255

---- snipped

dhcp-range=eth0,192.168.130.100,192.168.130.254,12h

... snipped

Doesn't dnsmasq run any verification checks before it runs? - if not, that is really bad - should not even start with something configured like that... Is there no dnsmasq utility either to verify the configuration files used by dnsmasq..

Don't use dnsmasq here (and seeing this really glad not using it), but the following

[root@karien bin]# dhcpd --version && named -v

isc-dhcpd-4.2.5

BIND 9.9.4-RedHat-9.9.4-50.el7_3.1 (Extended Support Version)

Use several VLANS here and tried to configure an incorrect range for dhcpd on a VLAN
It would not start and spit out this helpful error message

-- Unit dhcpd.service has begun starting up.
Oct 18 11:37:25 karien.sraellis.com dhcpd[32382]: Internet Systems Consortium DHCP Server 4.2.5
Oct 18 11:37:25 karien.sraellis.com dhcpd[32382]: Copyright 2004-2013 Internet Systems Consortium.
Oct 18 11:37:25 karien.sraellis.com dhcpd[32382]: All rights reserved.
Oct 18 11:37:25 karien.sraellis.com dhcpd[32382]: For info, please visit https://www.isc.org/software/dhcp/
Oct 18 11:37:25 karien.sraellis.com dhcpd[32382]: bad range, address 192.168.9.64 not in subnet 192.168.8.0 netmask 255.255.255.0

Regardless of what got changed - surely there should error displayed as soon as something becomes inconsistent...
While dhcpd was running, changed one of the sub-nets where dynamic addresses are assigned but no current leases in effect. Almost instantly dhcpd provided this error message and continued running, recognising the sub-net had disappeared... Had changed 192.168.8.0/24 to 192.168.9.0/24 - my 'play' VLAN

Oct 18 21:26:16 karien dhcpd: receive_packet failed on enp2s0.8: Network is down

Re-starting dhcpd now gives this helpful advice

Oct 18 21:39:18 karien dhcpd: No subnet declaration for enp2s0.8 (192.168.9.98).
Oct 18 21:39:18 karien dhcpd: ** Ignoring requests on enp2s0.8. If this is not what
Oct 18 21:39:18 karien dhcpd: you want, please write a subnet declaration
Oct 18 21:39:18 karien dhcpd: in your dhcpd.conf file for the network segment
Oct 18 21:39:18 karien dhcpd: to which interface enp2s0.8 is attached. **

If dnsmasq does no checking - then maybe webconfig could do some basic checks when the dnsmasq dhcp entries are displayed, created or updated? That would help avoid the situation the OP is faced with... No idea what the webconfig screen(s) look like...

A bit OT... The real reason didn't use dnsmasq in the first place? Couldn't find how to operate two dnsmasq dhcpd servers on the same sub-nets co-operating with each other. Same with dns. The ISC dhcpd server does this with a master and slave that communicate. Both therefore 'know' which leases it has assigned, as well as those by its 'partner'. If one goes down, the other will do everything. Then, when the failed system comes back up, it is brought 'up to date' by its partner... Similarly with BIND for dns. You can have a master and as many slaves as you want. Any changes made to the master get synced to the slave(s). The slave(s) will continue operating if the master goes down. Thus can take down a ClearOS server while the rest of the systems still function fully with dns and dhcp available.

Nick Howitt wrote:

Hi Tony,
I suspect the invalid condition can arise from configuring a NIC with a fixed IP, setting up the DHCP server on the NIC then changing the LAN IP/subnet. I'd need to test this scenario. iirc, on routers I've used, in this scenario they have automatically moved the DHCP settings to the IP/new subnet.

Rob, do you know if these two errant NIC's, eth0 and eth1, had previously been configured to use the 192.168.130.0/24 subnet?

Now that I think about it, I installed ClearOS and it defaults to no VLANs to allow you to set it up and connect initially. Then I added the two VLAN subnets so yes, at one point eth0 was on the 130 subnet.

I commented out the two DHCP lines for eth0 and eht1, deleted the eth1 interface from the ClearOS DHCP page. eth0 is also disabled now so it can't sneak in and mess stuff up.

It seems to have worked, I just need to let the leases run out on the clients and we'll see what they get assigned.

Thanks for your help Nick and Tony!

Rob

Hi Tony,
I've just tested by theory and it is right. If you set up a valid DHCP server then change the NIC IP/subnet, it leaves an invalid DHCP server set up. If you go to Webconfig > Server > Infrastructure > DHCP Server, it will show as Invalid and the only option is to delete it. I would have thought it would be better if it tracked to NIC subnet change or at least have the NIC subnet change jump straight to the relevant DHCP server settings.

Thanks Nick - so Webconfig detects the problem if you go back to configure dhcp settings.. so ClearOS does some basic checking, that is good. Your suggestion to add more, even better... In the meantime, if you change your network, re-check the dhcpd settings screen...

Anything in the logs recorded at the time you changed the NIC address and subnet to indicate an invalid dhcp config now existed? If nothing, would indicate no monitoring by default within dnsmasq for an invalid situation arising during operation . ISC dhcpd detected the NIC/subnet change as a problem within the same minute it changed... Checked the dnsmasq man pages online, (as they are not on my system ) and only found a reference to a syntax check. That is good, but a configuration file that has correct syntax can still be completely invalid...

There is nothing obvious in the logs. I have filed bug 17551.

[edit]
And it has just been changed to a feature request, which makes sense.
[/edit]