Page MenuHomeVyOS Platform

Make ip-address [OPTIONAL] (in dhcp-server -> static-mapping) to cope with "unfriendly" client-hostnames of IoT-Devices
Closed, ResolvedPublicENHANCEMENT


Hey everyone!
I have a practical enhancement proposal for you to consider.

What should be changed?

(*) Dhcp-server static-mapping for 'ip-address' FROM [REQUIRED] TO [OPTIONAL]
# set service dhcp-server shared-network-name <NAME> subnet <SUBNET> static-mapping <HOST>
 Possible completions:
 ip-address	Static mapping for specified IP address [REQUIRED] <-- change to: [OPTIONAL]
 mac-address	Static mapping for specified MAC address [REQUIRED]

What would this change accomplish?

The dhcp static-mapping function in VyOS requires both 'ip-address' and 'mac-address', where the host{} declaration in ISC-DHCP server, to which this is "translated", only requires a 'hardware ethernet' (mac-address). The omitted 'fixed-address' is then dynamically assigned from the 'range' of IPs available in the subnet pool [1].

Why should we care?

Many IoT/Smart-Home devices rely on a dhcp server, but send "unfriendly" client hostnames and working around this to have a "clean" dns resolution for clients like:

  • android-ed27272ab14acf44 --> TABLET
  • amazon-acc8xdsfs --> FIRETV
  • camera-12432XXwq --> IPCAM1
  • yeelink-light-strip1_miio77908737 --> LICHT3

means either you have to change the client's hostname(often not trivial or even possible) or set a static mapping for the device!!

Dhcp static-mapping is the only viable option, but in VyOS you have to also manually assign a static IP address for every single one of those devices, just to get rid of the "unfriendly" client hostnames - even if you simply don't care what IP addresses they get assigned.

Why is this a hassle?


(1) Pick up a new IP-Camera, Smart-Lights, HA-Sensor, Android Tablet, etc... 
(2) Look up the HW/MAC-Address (usually on the back of the device/packaging)
(3) vyos# set service dhcp-server shared-network-name LAN subnet static-mapping TABLET mac-address 'AA:BB:CC:DD:EE:FF'
(4) vyos# set service dhcp-server shared-network-name LAN subnet static-mapping TABLET ip-address ''
(5) <DONE> ($> ping TABLET | adb connect TABLET | nslookup TABLET |...)

But the mandatory <ip-address> (step (4) above) requires you to search for a free IP address outside of your dhcp subnet range.
With a significant and growing number of static hosts and IoT-Devices inside your LAN this becomes more and more a tedious job.
To prevent IP address collisions you must maintain a list of mapped/assigned IP addresses. That's not practical at all!

Could this change lead to a potential regression or even break VyOS?

I don't think so, because:

  • a host declaration like 'host TABLET { hardware ethernet 'AA:BB:CC:DD:EE:FF'; }' in dhcpd.conf is perfectly valid (see below [1])
  • it should be a minimum effort job, which requires only a small modification of the existing code - no extensive rewrite is needed
  • no need for special care of config migration scripts, since older Vyatta Core versions are no longer supported [2]

I think this could be considered a significant improvement for home and small office environments, where keeping track of statically assigned IPs for IoT/Smart-Devices is not desirable or practical.

Thank you all for the great work!



The host statement
The host declaration provides a way for the DHCP server to identify a DHCP or BOOTP client.
[...] The host declarations will only match a client if one of their fixed-address statements is viable on the subnet (or shared network) where the client is attached.
Conversely, for a host declaration to match a client being allocated a dynamic address, it must not have any fixed-address statements. [...]



Difficulty level
Easy (less than an hour)
Why the issue appeared?
Will be filled on close

Event Timeline

krassle triaged this task as Normal priority.Jun 14 2019, 12:54 AM
krassle created this task.

Fix is commited in current branch (rolling/Equuleus), it can be tested with the latest rolling build and task status updated.

Can be set to finished on 1.3 Equuleus

I've tested the fix on latest rolling and so far it works as expected.
Thanks for the quick patch!