DHCP dynamic clients not showing as expected

Getting Started with IPFire
42

So you have 7 clients listed in the leases file, all with leases that have expired after the full default lease time you have set.

What should normally happen is that after 50% of the lease time the dhcp client says to the dhcp server “hallo, I am still here, please continue my lease please”
The server then says “okay, I have updated your lease info here”.

What is interesting is that client IP’s 5, 10, 14 & 11 have the default lease time of 2.5 days between the start and end date/time. client IP’s 3, 9 & 24 have twice the default lease time (5 days) between the start and end date/time.

It looks like either the client never requested a renewal to the server or the server refused it for some reason and the lease just expired.

I also don’t understand why if the leases are still in the file but expired, why they don’t show up in your Current dynamic leases table but just crossed through because they are expired.

Anyway, let’s try and find out what happened with the renewal. Have a search in the dhcpd log on the System Logs WUI page, searching around 2023/03/20 21:29:00 (50% of the default lease time) and look for all the entries for 192.168.10.5

Those dhcpd messages should give some indication of why the leases were not renewed.

1 Like
43

Mind you, that is only the WiFi. Just saying so you don’t confuse GREEN with BLUE. Or BLUE with GREEN. I need more coffee.

No entries at all for around that time.

20:58:10	dhcpd:	DHCPREQUEST for 192.168.1.244 from 00:21:b7:8e:21:93 (Printer) via green0
20:58:10	dhcpd:	Wrote 0 deleted host decls to leases file.
20:58:10	dhcpd:	Wrote 0 new dynamic host decls to leases file.
20:58:10	dhcpd:	Wrote 56 leases to leases file.
20:58:10	dhcpd:	DHCPACK on 192.168.1.244 to 00:21:b7:8e:21:93 (Printer) via green0
22:37:38	dhcpd:	DHCPREQUEST for 192.168.1.30 from 0c:c4:7a:6e:45:34 via green0
22:37:38	dhcpd:	Wrote 0 deleted host decls to leases file.
22:37:38	dhcpd:	Wrote 0 new dynamic host decls to leases file.
22:37:38	dhcpd:	Wrote 56 leases to leases file.
22:37:39	dhcpd:	DHCPACK on 192.168.1.30 to 0c:c4:7a:6e:45:34 via green0

No entries at all for 192.168.10.5

44

That means that client 192.168.10.5 never made any request to IPFire dhcp for a lease renewal.

You need to look at the dhcp logs on that client to see what is happening.

What sort of machine is that client? Is it a Linux, MAC or Windows PC or is it an IOT type device.

When you saw the entries in the Current dynamic leases table did you see both Green and Blue clients present or only the Blue ones?

The fact that there are no machines with IP’s from the Green network leads me to believe that they never got seen as dynamic leases. Are all the Green machines having fixed or static leases?

The dhcpd.lease~ being empty and only those 7 machines being in dhcpd.leases means that no other dynamic leases were requested and provided. As you can see it is a persistent file unless both the Green and Blue subnets have been disabled in the WUI page.

Here is the description of the dhcpd.leases file.

The Internet Systems Consortium DHCP Server keeps a persistent database of leases that it has assigned. This database is a free-form ASCII file containing a series of lease declarations. Every time a lease is acquired, renewed or released, its new value is recorded at the end of the lease file. So if more than one declaration appears for a given lease, the last one in the file is the current one.

In order to prevent the lease database from growing without bound, the file is rewritten from time to time. First, a temporary lease database is created and all known leases are dumped to it. Then, the old lease database is renamed DBDIR/dhcpd.leases~. Finally, the newly written lease database is moved into place.

The lease file is a log-structured file - whenever a lease changes, the contents of that lease are written to the end of the file. This means that it is entirely possible and quite reasonable for there to be two or more declarations of the same lease in the lease file at the same time. In that case, the instance of that particular lease that appears last in the file is the one that is in effect.

This would suggest to me that the leases file at that time had 56 leases written in it. As there are now only 7 leases in dhcpd.leases and 0 in dhcpd.leases~ that suggests to me that in the intervening period the green and blue subnets must have been disabled and dhcpd saved as this wipes clean the dhcpd.leases files.

I have also noticed that three of the 7 leases in your file are for the same device “android-dhcp-13” which has the changing MAC address for each connection it makes, hence it did not get a renewal of the lease but got a new lease.

1 Like
45

18:5e:0f:11:e7:43 / 192.168.10.5
Meh, that client is currently not available. Lansweeper or ARP has no entry for it either.

Lest try another one perhaps?

As for the DHCP leases, when they showed up last time it was a table in two sections. One for GREEN and one for BLUE, both in the lower section of the DHCP page. BLUE below GREEN, IIRC.

46

That would be a good idea. Maybe find a machine that is in the ARP table and on the Green subnet as that is likely to be a wired system and therefore permanently running.
If you can restart the dhcp client on that machine then it should request a renewal of it’s lease. Then we can see if that is registered on the Current dynamic leases table and in the dhcpd.leases file.

I would suggest setting your Default lease time back to 60 mins as then every 30 mins the client, if still running, should request a lease renewal for the same IP. Then if that entry disappears from the Current dynamic leases table we can check the contents of dhcpd.leases and the dhcpd log file to see what happened at the renewal stage.

1 Like
47

After checking lansweeper I have these currently available on my BLUE

192.168.10.21	Local Wifi	Network device	192.168.10.21	
airCube	Local Wifi	Webserver	192.168.10.2	
Aqara-Hub-M2-AFE2.homered.conram.it	Local Wifi	Network device	192.168.10.6	
fwipfire.homered.conram.it	Local Wifi	Network device	192.168.10.1	
Ipad/Iphone 192.168.10.12	Local Wifi	IOS	192.168.10.12	
PANDRM1.homered.conram.it	Local Wifi	Network device	192.168.10.20	
Samsung.homered.conram.it	Local Wifi	Webserver	192.168.10.15	
SDongleA-HV2270084630.homered.conram.it	Local Wifi	Network device	192.168.10.25	
TANDRM1.homered.conram.it	Local Wifi	Network device	192.168.10.10
48

Choose one of those that is intended to be permanently running and then try to restart the dhcp client on that machine. If not possible, the other option is to reboot the machine in question.

See my post sent just before yours about the Default lease time.

1 Like
49

Ok, easy enough.

Lease time set to default 60. Max 3600.

Permanently on, my FileShare and my NAS. GREEN
Both have fixed IP: 192.168.1.10 and 100 respectively.

I can reboot both, simpler. Then I guess I make a note of the time I rebooted them.

Starting with NAS, that runs Asustor OS.
Arp table entry before reboot.

192.168.1.100 dev green0 lladdr 10:bf:48:89:f3:3c REACHABLE

It has a Static DHCP lease:

image
image1152×35 2.53 KB

I will reboot that in a few and get back.

50

So.

This is the log entry for System > DHCP

12:04:41	dhcpd:	DHCPDISCOVER from 10:bf:48:89:f3:3c via green0
12:04:41	dhcpd:	DHCPOFFER on 192.168.1.100 to 10:bf:48:89:f3:3c via green0
12:04:41	dhcpd:	Dynamic and static leases present for 192.168.1.100.
12:04:41	dhcpd:	Remove host declaration fix6 or remove 192.168.1.100
12:04:41	dhcpd:	from the dynamic address pool for 192.168.1.0/24
12:04:41	dhcpd:	DHCPREQUEST for 192.168.1.100 (192.168.1.1) from 10:bf:48:89:f3:3c via green0
12:04:41	dhcpd:	DHCPACK on 192.168.1.100 to 10:bf:48:89:f3:3c via green0

This is the entry in ARP

192.168.1.100 dev green0 lladdr 10:bf:48:89:f3:3c REACHABLE

Copy of contents in dhcpd.leases

# The format of this file is documented in the dhcpd.leases(5) manual page.
# This lease file was written by isc-dhcp-4.4.3-P1

# authoring-byte-order entry is generated, DO NOT DELETE
authoring-byte-order little-endian;

lease 192.168.10.5 {
  starts 0 2023/03/19 09:29:31;
  ends 2 2023/03/21 21:29:31;
  tstp 2 2023/03/21 21:29:31;
  cltt 0 2023/03/19 10:21:25;
  binding state free;
  hardware ethernet 18:5e:0f:11:e7:43;
  uid "\001\030^\017\021\347C";
  set vendor-class-identifier = "MSFT 5.0";
}
lease 192.168.10.10 {
  starts 0 2023/03/19 09:41:04;
  ends 2 2023/03/21 21:41:04;
  tstp 2 2023/03/21 21:41:04;
  cltt 0 2023/03/19 09:41:04;
  binding state free;
  hardware ethernet c4:7d:9f:6f:67:35;
  uid "\001\304}\237og5";
  set vendor-class-identifier = "android-dhcp-13";
}
lease 192.168.10.14 {
  starts 1 2023/03/20 11:05:50;
  ends 3 2023/03/22 23:05:50;
  tstp 3 2023/03/22 23:05:50;
  cltt 1 2023/03/20 17:45:35;
  binding state free;
  hardware ethernet 52:e0:0c:a9:2f:84;
  uid "\001R\340\014\251/\204";
  set vendor-class-identifier = "android-dhcp-13";
}
lease 192.168.10.11 {
  starts 1 2023/03/20 18:48:08;
  ends 4 2023/03/23 06:48:08;
  tstp 4 2023/03/23 06:48:08;
  cltt 1 2023/03/20 18:48:08;
  binding state free;
  hardware ethernet be:43:2b:ab:03:83;
  uid "\001\276C+\253\003\203";
  set vendor-class-identifier = "android-dhcp-13";
}
lease 192.168.10.3 {
  starts 1 2023/03/20 15:39:45;
  ends 6 2023/03/25 15:39:45;
  tstp 6 2023/03/25 15:39:45;
  cltt 1 2023/03/20 15:39:45;
  binding state free;
  hardware ethernet 0a:a7:cb:4d:1e:e4;
  uid "\001\012\247\313M\036\344";
}
lease 192.168.10.9 {
  starts 1 2023/03/20 18:20:30;
  ends 6 2023/03/25 18:20:30;
  tstp 6 2023/03/25 18:20:30;
  cltt 1 2023/03/20 18:20:30;
  binding state free;
  hardware ethernet 1a:30:9a:c6:d0:24;
  uid "\001\0320\232\306\320$";
}

It only lists BLUE devices.

What next?

51

First suggestion, separate your dynamic and static ( fixed ) leases sets.
This recommended in the dhcpd messages and in the WUI ( thanks to Adolf’s patch! ) also.
ISC’s dhcp server assumes this separation. In the documentation is stated, that the behaviour for overlapping regions is undefined.
One reason is the process of assignment of dynamic leases. For a dynamic request ( no fixed definition exists for the MAC ) an unassigned IP is selected. Before it is issued to the client, a check is made whether the IP can be reached by ICMP.
A static or fixed IP of an inactive device can be chosen. If the device becomes active afterwards, the IP is doubled.

52

Not sure I follow you Bernard, “set”?

ISC? Separation?

I can guess, but just in case I am wrong, please elaborate.

As for static IP’s getting doubled up, I see no indication of that. The only thing I find that may not have been addressed is if a device has both a “host” entry and a static IP entry. Which a few of my devices have in order to be able to connect to them knowing their hostname and not having to use the IP.

Maybe this is an indication of that?

12:04:41	dhcpd:	Dynamic and static leases present for 192.168.1.100.
12:04:41	dhcpd:	Remove host declaration fix6 or remove 192.168.1.100
12:04:41	dhcpd:	from the dynamic address pool for 192.168.1.0/24

Dynamic and static leases present for 192.168.1.100.

Remove host declaration fix6 or remove 192.168.1.100 from the dynamic address pool for 192.168.1.0/24

53

This thread has become a bit long now.
Just to be on the same level of information:
@sec-con ,

  • how are your green and blue networks defined?
  • how did you define your IP pools?
    static ( not handled by dhcpd )
    fixed ( fixed assignment by dhcpd to cleints, identified by MAC )
    dynamic ( all other clients handled by dhcp )
  • are the above parts not overlapping?

As stated several times, it is necessary to separate these ranges. BTW, this sepation helps for client identification by the admininstrator also.
As far I can see, the file dhcpd.leases holds the dynamic leases. Fixed leases are defined in dhcpd.conf.

1 Like
54

If the devices have a static IP defined on the client or a Fixed Lease on IPFire then they will not show up in the dhcpd.leases file. 192.168.1.100 has a Fixed Lease defined in the Fixed Leases table. This means that it has a fixed lease definition in dhcpd.conf and that means that dhcp will not treat it as a dynamic lease.

As @bbitsch has said I would also recommend separating your dynamic ip range so that all your fixed leases are outside of it. With CU174 you can tell which ones overlap as the IP will be highlighted in red.

This overlap of dynamic and fixed leases is just causing confusion on what should be expected to show up in the Current dynamic leases.

Based on your fixed leases list then the following IPs will never show in the Current dynamic leases table.

192.168.1.5, 10, 40, 42, 50, 52, 100
192.168.10.2, 10, 25

because they all have a fixed lease defined. At the same type all of them are also in the Dynamic range that you have defined for Green and Blue, so you have a 100% hit for all your Fixed Lease IP’s overlapping with the Dynamic Range. That is why you are getting all those messages like

dhcpd:	Dynamic and static leases present for 192.168.1.100

and there will be the same messages for the other Fixed Leases.

1 Like
55

Going to throw in 174 before continuing this.

56

CU174 doesn’t change an inconvinient configuration. :wink:

57

I get that.
Still no explanation for why my devices without fixed address do not show up.

@bbitsch
From your suggestions I think you want me to create another IP range where I put my fixed addresses only.

I must admit I never did consider needing additional ranges, first all was GREEN with some static addresses, then I created BLUE with the pinhole for trusted devices. That covers all I need for now and has been fairly simple to setup in IPFire, much thanks to the coloured methodology you have implemented.

When looking to add addresses you do not want to change, because you want them to be available at the same “place” always, most other manufacturers just have an option to pickup a dynamic address and set is as static. I know this for a fact. You can do it with Asus, Mikrotik, Ubiquiti (EdgeOS), OPNSense and Zyxel. I have first hand experience from all of these. And their DHCP listing still works. So they all do it wrong?

So I ask you, give me a concrete example, with some screenshots, what do you want me to do so I can solve my original issue with DHCP dynamic leases not showing anywhere but in ARP and BLUE Access /wireless.cgi > Current DHCP leases on BLUE. I have some fixed addresses there as well you know, like to my AP’s on 192.168,10.2 and 192.168.10.3, well the last one is not implemented yet.

58

The simplest way to do this is to change the green dynamic range from

Start 192.168.1.2
End 192.168.1.250

to

Start 192.168.1.101
End 192.168.1.250

That way your existing green fixed leases can stay the same and you still have 150 IP’s to be assigned for dynamic green clients. You also still have some IP’s left for further fixed leases as you are only using 7 fixed leases from 99 available IP’s.

For the Blue dynamic range, change it from

Start 192.168.10.2
End 192.168.10.250

to

Start 192.168.10.30
End 192.168.10.250

This way again your existing blue fixed leases can stay as they are, you still have 221 IP’s to be assigned to your dynamic blue clients. You also still have IP’s available for further fixed lease on blue as you are only using 3 fixed leases from 29 available IP’s.

Once you have made the above changes and pressed the Save button on the DHCP WUI page then it would be best to reboot all the clients so they request IP’s and there is no confusion about which sort of IP they have each got.

Then we can see what shows up in the Current dynamic leases table and in the dhcpd.leases file.

4 Likes
59

Sure, I can do that,

Start 192.168.1.101
End 192.168.1.250

but

ok, perhaps a stupid question, but I do not get this one.

If I do not have a DHCP giving out addresses for the fixed leases, how do they get the IP’s? Do I not need a server giving out every address regardless of scope?

60

No such thing as a stupid question. Questions are how one learns.

The DHCP server gives out both the dynamic and fixed leases that you have specified. It is just that the server will define the IP to always be used for that MAC address, so that IP will only ever be offered to that specific client.

If you look in your /etc/dhcp/dhcpd.conf file you have a section for the green subnet that has a line

range 192.168.1.2 192.168.1.250;

That is the definition of the dynamic IP’s that IPFire will give out.

Later in the same file you have entries such as

host fix1 # q-xxxxx
{
	hardware ethernet XX:XX:XX:XX:XX:XX;
	fixed-address 192.168.1.10;
}

This is one of your fixed lease definitions. I have just anonymised the MAC address.

Every time that client requests a lease the IPFire DHCP server will recognise it from its MAC address and supply it with the IP 192.168.1.10

Any client with a MAC address that is not found in the fixed lease list will be given the first available IP in the Dynamic range that you have specified.

That is when a problem can occur with having the dynamic and fixed lease IP’s overlap because if a fixed lease client happens to be turned off then it’s IP could be given to a dynamic client and when the fixed lease client turns back on it will find it’s IP has been used and you could end up with a duplicate IP being in existence.

Hope this helps clarify a bit.

Feel free to ask more questions.

7 Likes
61

I ran in to a snag with my solar converter, can’t do any network changes on it, not authorized, so while I sort that I am temporarily freezing any changes on my network.

Seems I do not have the access required in the app handling that, to actually put it back on the network or manage its connection. Bummer.