Blue leases clean up

How can o clean up the unused blue leases. I cannot find a remove or delete. It is also assigning new ip addresses to existing mac addresses on the list. Do i need to assign static ip’s to those?


If the same MAC address receives changing IPs, the pool of IPs is perhaps small. The old IP is handed out to another device meanwhile.

Hi @andy120

To remove all DHCP leases, the only easy solution is to disable DHCP for BLUE → Save and then enable DHCP for BLUE again → Save.

That way all concessions are removed.

Both iPhones and Androids have random MACs to safeguard privacy. It is not uncommon to see the same IP with multiple leases. Gives problems in MAC Filtering. This option can be disabled on these devices.



About these ‘security features’ of changing MACs. This isn’t really efficient. The basic definition of the MAC addresses tries to create an unique identification (name) of a device in a network. Changing this name changes the identity. So an IP pool may be rapidily exhausted, because the server dhcpd tries to retain expired leases for a new request of the same device ( identified by his name ).

Therefore using this smartphone feature inside a local network isn’t good. It makes administration of access rights of known device unnecessaryly complicated.

Buenas tardes @bbitsch.

I say this as I believe this Random MAC functionality is enabled by default on these devices. That if you had this problem of an IP with different MACs, you should disable it on the iPhone or Android.


Hello @roberto ,

you’re right. These features are often enabled by default. But this doesn’t make it better. :wink:
Many smartphones and tablets insist to use the Google DNS server. But this can be handled by redirection and so their ignorance about settings from DHCP server can be ‘cured’.
The MAC switching results in less manageable system and each administrator is free to refuse those devices. My opinion.


1 Like

i am assigning manual ip’s on each device to match the auto assigned one so the ip is listed on the enabled list. i then blue dhcp off, save, on, save. it wiped the unused leases and the enabled’s are still listed and active.

Thanks guys

1 Like

@andy120 , just to comment.

Fixed leases establish a relation ( MAC, IP ), which isn’t valid for changing MACs.
If you configure static IPs on your devices, don’t forget to config all parameters supplied by dhcpd ( values in the DHCP WebGUI page ).

1 Like

Thanks, forgot about the random MAC’s, old phone did not do that new phone was wondering why stopped letting my camera access out (tied to IP) when looked had a different IP than I had in my rules, was puzzled but now this makes sense need to disable.

1 Like

interesting, i have been under the impression that mac’s were permanent to a device from manufacture.


This is what appears on my Android 12 phone:

In iPhone I don’t know how it looks as I don’t have any Apple device.


This is true for most devices. But smartphone manufacturers invented this ‘security feature’. In a universe of mobiles this possible, because a mobile phone uses the IMEI for identification, which is unique.
Didn’t research from which pool of MACs these changing names are chosen. If smartphone manufacturers have reserved a set of MACs, this would be vasting the domain of possible values. Personally I don’t like that, IPv4 addresses are limited by those buy outs also, IMHO.

So, you have this wrong setting also. :wink:


Whether it is considered wrong or not depends on circumstances i would say.

When connecting to your home IPFire network you probably want it to be the fixed phone mac.

When you are in a coffee shop you might want the randomised mac so they, or whoever can access their network, can’t track your browsing etc via your mac connection.

Depends on randomisation. I think the quality of this function must be very limited. You can’t chose just an arbitary number, because the uniqueness of MAC addressing must not be violated. In an ethernet(like) network the MAC is a bijective id.

A MAC can either be a Universally Administered Address (UAA) or a Locally Administered Address (LAA).
The randomised mac address is an LAA. The Phone mac address is a UAA and the two sets of mac addresses are separate and defined by the second least significant bit of the second character of the mac address. If the second character of the mac address is a 2, 6, A or E then the mac address is an LAA. Everything else is a UAA.
So any LAA will never match with a UAA so it will always be unique in that sense but I can’t believe that any LAA can ever be guaranteed to be unique across all places where an LAA is being defined.

I have no idea how randomised this LAA actually is but once defined I am not sure if it changes again. If you create another wifi link it will have a different randomised mac. So creating a new wifi connection uses a different randomised LAA mac. Changing from the randomised mac to the phone mac and back again doesn’t change the randomised mac on my android phone. Also turning the phone completely off and turning it back on also doesn’t change that randomised mac.

So the randomised mac is different for each wifi connection but stays the same after having been defined.

One additional complexity that will come is that the phone OS developers are working on the option to be able to change this randomised mac every 24 hours. This was tested in one of the pre-release versions of ios14 but was removed in the final release. Android 11 has it available but only via an advanced developers only screen.
I am sure that this will eventually be released and just like the randomised mac address it will at first be off by default and then in a later release it will be on by default and you will have to actively turn it off.

So keep an eye out for the future, the phone mac’s will change even more often.


I’ve search a bit for this mechanism.

Adolf is right. The randomised MACs are LAAs. So they can’t conflict with the ‘real’ MACs ( UAAs ).
But to my comprehension, a LAA needs some administration in the local network ( as the name implies ).
How is this local administration done? It doesn’t seem there is a ‘master’ device, chosen by whatever procedure.
So there is some probabilty, that two indepent chosen MACs from devices of the same type/brand/manufacturer are equal, which violates local uniqueness.

Another problem arises from the anonymity targeted. To administer a gateway with firewall like IPFire, one should be able to identify the devices connected.
To tolerate anonymous devices, there should be IMHO a special network for these with limited rights. This includes no service access in the local green and blue networks. That is possible, but I suppose not really wanted in many cases.