My DHCP server on 183 seems to died somehow.
It stopped renewing IPs and then after stopping it and starting again I have got:
08:50:28 dhcpd: lease 192.168.2.161: no subnet.
08:50:28 dhcpd: lease 192.168.2.171: no subnet.
08:50:28 dhcpd: lease 192.168.2.138: no subnet.
08:50:28 dhcpd: lease 192.168.2.139: no subnet.
08:50:28 dhcpd: lease 192.168.2.142: no subnet.
08:50:28 dhcpd: lease 192.168.2.145: no subnet.
08:50:28 dhcpd: lease 192.168.2.163: no subnet.
08:50:28 dhcpd: lease 192.168.2.160: no subnet.
08:50:28 dhcpd: lease 192.168.2.155: no subnet.
08:50:28 dhcpd: Wrote 0 deleted host decls to leases file.
08:50:28 dhcpd: Wrote 0 new dynamic host decls to leases file.
08:50:28 dhcpd: Wrote 0 leases to leases file.
08:50:28 dhcpd:
08:50:28 dhcpd: No subnet declaration for red0 (no IPv4 addresses).
08:50:28 dhcpd: ** Ignoring requests on red0. If this is not what
08:50:28 dhcpd: you want, please write a subnet declaration
08:50:28 dhcpd: in your dhcpd.conf file for the network segment
08:50:28 dhcpd: to which interface red0 is attached. **
08:50:28 dhcpd:
08:50:28 dhcpd:
08:50:28 dhcpd: No subnet declaration for green0 (192.168.2.3).
08:50:28 dhcpd: ** Ignoring requests on green0. If this is not what
08:50:28 dhcpd: you want, please write a subnet declaration
08:50:28 dhcpd: in your dhcpd.conf file for the network segment
08:50:28 dhcpd: to which interface green0 is attached. **
08:50:28 dhcpd:
08:50:28 dhcpd:
08:50:28 dhcpd: Not configured to listen on any interfaces!
08:50:28 dhcpd:
08:50:28 dhcpd: If you think you have received this message due to a bug rather
08:50:28 dhcpd: than a configuration issue please read the section on submitting
08:50:28 dhcpd: bugs on either our web page at www.isc.org or in the README file
08:50:28 dhcpd: before submitting a bug. These pages explain the proper
08:50:28 dhcpd: process and the information we find helpful for debugging.
08:50:28 dhcpd:
08:50:28 dhcpd: exiting.
It was not going to properly restart on few probes.
So I restarted the whole router.
It finally helped.
Other strange issue is my old devices who never used dynamic MACs are shown under dynamic MACs from time to time. Thatās very strange to me ā¦
One of them was cut-off from network this morning. Could be itās DHCP server related.
That is true @bbitsch so something must have got very wrongly defined or corrupted but only in the config or some settings files and not the core code because a reboot got everything working again.
I have been able to get the same messages (including the one about red0) in my dhcp logs by disabling both my blue and green dhcp entries on the WUI DHCP page and pressing the Save button.
Disabling both the subnets causes the subnet entries in dhcp.conf to be removed and then the dhcpd daemon is stopped but it looks like there is enough time for the daemon to notice that the conf file has no subnets defined now.
I will check out the code to see why this is happening. I donāt recall every seeing these log messages in the past when disabling all dhcp subnets.
If both blue and green subnets (or just green subnets if that is all that is installed) are disabled then the daemon should just stop. Maybe the order of things needs to be changed.
08:40:45 dhcpd: reuse_lease: lease age 20 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.2.160
08:40:45 dhcpd: DHCPREQUEST for 192.168.2.160 from ba:ea:baxxxxx via green0
08:40:45 dhcpd: DHCPACK on 192.168.2.160 to ba:ea:baxxxxxx via green0
08:50:28 dhcpd: lease 192.168.2.133: no subnet.
08:50:28 dhcpd: lease 192.168.2.147: no subnet.
08:50:28 dhcpd: lease 192.168.2.148: no subnet.
08:50:28 dhcpd: lease 192.168.2.150: no subnet.
08:50:28 dhcpd: lease 192.168.2.159: no subnet.
08:50:28 dhcpd: lease 192.168.2.149: no subnet.
Log shows common msgs exchange. No problem reported before. But as I stated I wanted to restart DHCP server because of strange symptoms I saw - like stations not connected. Once I clicked disable/enable log was filled with those āno subnetā messages.
Have just tested that those strange log msgs are filled on ādisablingā only. After server is enabled log is filled with std msgs.
Could be itās expected behavior on setting server off.
I have just looked through the code and if both blue and green are disabled then the code removes the start links from the init process and then it runs the restart command.
The restart command tries to run the dhcp daemon which then complains because the dhcp.conf file has no subnets defined.
I suspect these log messages have been present for a long time but most people donāt look in the logs after disabling both blue and green subnets and so it hasnāt been seen. I certainly have not seen them but I probably havenāt looked at those times which are not that frequent.
If both subnets are disabled then I think the code needs to run the stop command. The restart command should only be run when either green or blue or both are enabled.
I will look at submitting a patch to correct this behaviour.
EDIT:
Have looked back in the git repo and the restart command was being used in Core Update 30, the first entry in the IPFire git repo.
So the messages have been in the logs since at least 14 years!!
I canāt explain the āno subnetā errors fully.
But when no networks are defined for a running dhcpd each DHCP renewal request must result in this message.
No idea why 10 minutes earlier a request is acked as expected.
Have found another issue with DHCP.
And it ālocksā my clients in no-internet state.
The problem is that ones added static mapping canāt be revoked.
If you revoke it server is not going to offer new IP from pool but cuts communications with:
DHCPREQUEST for 192.168.2.33 from b4:fb:XXXXX via green0: unknown lease 192.168.2.33
.33 was static mapped before, assigned and used by that client.
What means āI just do not like numer you asked for and will not give you any otherā
What do you mean by revoked? Do you mean that you have disabled or deleted an existing fixed lease in IPFire. If that is the case then the client will continue trying to access the lease it had previously been given by IPFire until the lease time has expired. The default lease time, if you have not altered it, is 60 minutes. IPFire can not clear the old lease from the client.
If the above is the problem you are having (I am not totally sure from your description of the problem) then you have the following options.
Wait for the lease time to expire and then try and reconnect the client to IPFire,
Restart the dhcp package on your client machine. This should clear its cache and it will not ask for the previous lease that no longer exists.
Reboot the client machine which will also clear the dhcp cache on the client and make it ask for a fresh lease.
@bonnietwin Yes, enabling then disabling static leases left clients with old/static IP. While for my understanding end experience clients should be feed with new IP from pool on next request. While they are not in that case.
I used to shorten lease time to 10mins for testing.
I will try and test this out, when I can get some time, on my vm testbed to see what result I get with my Linux clients.
When I have gone through changes in my IPās I donāt recall having any problems as long as I rebooted the clients or restarted their DHCP clients but it is a while since I have been changing IPās.
The message clearly states that there is no definition of the lease for green0.
What do you mean by āstatic mappedā? Have you defined a fixed lease and saved/restarted dhcpd?
If the client uses a static definition ( IP, DNS server, gateway ) it should request this IP from the server.
Guys,
I think the original problem is not and issue. Just a strange msg on DHCP server going down.
Second is a problem for me so I switch to other DHCP server.
In that case if a client got an IP from static pool (IP hard joint with MAC address) server will never deliver a dynamic IP from dynamic pool even after deleting/disabling a static mapping.
My clients seemed to be locked on waiting for new offer from server.
Could be there is a 1h timeout for that. Cant wait so long to test it.
I just changed DHCP server to other and stopped one on IPFire.
I just tried that with my windows client.
āNiceā behaviour. The requests are not answered by IPFire, log message is āunknown leaseā ( thatās right, there is no fixed lease definition ), after 14 attempts windows gives up and uses the old lease.
If I remember right, after x requests without acknowledgement ( NAK answer or no answer ) the client should switch to startup ( discover packets ).
That makes it sound like it is an issue with windows clients then.
I just tried it on my vm setup. I had a linux client connected with a fixed lease from my vm IPFire. If I restarted the dhcpcd client on my linux system it got back the existing fixed lease IP.
I then disabled the fixed lease definition in the IPFire WUI DHCP Server page. Then I restarted the dhcpcd client on my linux system.
Client first of all tried to rebind to the previous fixed lease IP.
Then it got the message DHCP lease expired.
Then it solicited a DHCP Lease from the IPFire Server.
It was offered a new IP lease from the dynamic range.
The client accepted the new dynamic lease.
So the Linux client very happily changed from the Fixed Lease to the Dynamic Lease with no problems.
@paku are you using a Linux client or a Windows client?
EDIT:
I just looked at the IPFire DHCP Server logs and there was the unknown lease message twice, so the Linux dhcpcd client tried the old IP twice, separated by 5 seconds, then the client understood that the old lease had been expired and it then did the soliciting for a lease, which on the server can be seen by a DHCP Discover message coming from the client on green.
Then the server offers a new IP from the dynamic range. The client then formally asks for that IP and the server formally acknowledges that the new IP has been taken.
From your logs it looks like the client asks for the old lease but does not recognise that the IP has been expired and that it should request a new IP and so nothing further happens. The server will only offer a new lease if a client has solicited a new IP.