Page MenuHomePhabricator

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

Description

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>
[TAB]
 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?

Scenario:

(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 192.168.1.0/24 static-mapping TABLET mac-address 'AA:BB:CC:DD:EE:FF'
(4) vyos# set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 static-mapping TABLET ip-address '192.168.1.155'
(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!

Cheers,
krassle

[1] https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdconf

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. [...]

[2] https://github.com/vyos/vyos-1x/commit/4c070a73a3fac283f5ab8ca679bc1ac191565ef6

Details

Difficulty level
Easy (less than an hour)
Version
-
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.
krassle updated the task description. (Show Details)Jul 1 2019, 3:12 PM
pasik added a subscriber: pasik.Jul 2 2019, 3:26 PM
jjakob added a subscriber: jjakob.Jul 4 2019, 10:40 PM

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

krassle closed this task as Resolved.Jul 22 2019, 10:11 PM

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

c-po moved this task from Need Triage to Finished on the VyOS 1.3 Equuleus board.Aug 5 2019, 12:22 PM