Page MenuHomeVyOS Platform

DHCP server prepends shared network name to hostnames
Closed, ResolvedPublicBUG


root@vyos:~# cat /etc/hosts localhost

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts        vyos.adriatika.local vyos       #vyatta entry        VoIP_PanasonicNCP500_IPCMPR.voip.adriatika.local        #on-dhcp-event 0:80:f0:d1:6c:f6        VoIP_IPPBX.voip.adriatika.local         #on-dhcp-event 0:c:29:32:9d:6c

why it add "VoIP_" in front of hostname?


Difficulty level
Normal (likely a few hours)
VyOS 1.2.0-beta1
Why the issue appeared?
Design mistake
Is it a breaking change?
Unspecified (possibly destroys the router)

Event Timeline

Could you tell us why these hostnames are wrong and what are the right hostnames you expected?

syncer claimed this task.
syncer triaged this task as Low priority.
syncer added a subscriber: syncer.

i believe that forums or questions section is more correct for such requests.
so i now will close this task, but feel free to create a question on forums or here in phabricator.
Basically, VyOS by itself not adding anything(if not configured to do so)
check your client hosts configuration, it's how they present themselves to DHCP server

Because hostname is ippbx for this one: VoIP_IPPBX.voip.adriatika.local

For part of hosts it add VoIP_? for part not. VoIP - is shared-network-name on DHCP. VoIP_spa8000-2.voip.adriatika.local #on-dhcp-event 0:25:9c:6e:8:64 VoIP_spa8000-1.voip.adriatika.local #on-dhcp-event 20:aa:4b:57:f4:80 pool-adm-KX-HDV100RU.voip.adriatika.local #on-dhcp-event 8:0:23:e1:71:b

syncer added a project: VyOS 1.1.x (1.1.8).
syncer added a subscriber: EwaldvanGeffen.

@EwaldvanGeffen it can be that we have issue with dhcp event script
it looks like that output of tools used in that script changed
and now that script produce a mess in /etc/hosts

May be you can run tcpdump -nvvv port bootps on your host to catch your client's requests to make sure that clients request hostnames without prefixes?

As you can see: Hostname Option 12, length 12: "AdrSPA8000-1"
cat /etc/hosts | grep spa8000-1 VoIP_spa8000-1.voip.adriatika.local #on-dhcp-event 20:aa:4b:57:f4:80

I added one more Cisco SPA8000 to my network, at beginning it was added normally, but when i make it static-mapping, i got:
cat /etc/hosts AdrSPA8000-3.voip.adriatika.local #on-dhcp-event d0:c7:89:78:fb:f0 - it was DHCP VoIP_spa8000-3.voip.adriatika.local #on-dhcp-event d0:c7:89:78:fb:f0 - it's DHCP+static-mapping

so this mean, that problem can be in static mapping

Yep... And really, I understood that all hosts with shared-network-name prefix are static mapped.

Hello @EwaldvanGeffen
can you check this whenever you have time,
we traced it to a static host mapping(but i'm not sure)

From the looks of the script it seems this hostname is coming from the DHCP-server upstream. I wonder if this behaviour is controlable.

Edit: it might be on purpose. To either parse intelligently into something (where the subnet network matches a specific PTR) or because otherwise it's to guarantee uniqueness of host-names accross multiple pools that might have conflicting host-names. I just wonder if this behaviour also shows on dhcp-hostname-non-client when the second entry arises or from dns recursion (another cool option we could support if we don't already).

The log file from that script provides the answer whether it's from upstream. I just don't know yet where to find it atm. /sleep

this hostname is coming from the DHCP-server upstream

VyOS is single DHCP server in this network.

it's to guarantee uniqueness of host-names accross multiple pools that might have conflicting host-names

It looks reasonable, but "it's not bug, it's future" should be configurable i think... This behavior prevents me.

Could you provide the contents of "sudo vi /opt/vyatta/etc/dhcpd.conf"? It could be related to previously fixed / Reading into it.

check this thread

set service dhcp-server global-parameters "use-host-decl-names on;"

Should solve this issue
@EwaldvanGeffen should we adopt this as default value?

Hi, I'm the guy from the reddit thread.

This behavior stems from the file. When this file parses the static mapping configuration, by default it will append the "host prefix", which is the shared-network-name, to the host-name in the final dhcpd.conf.

This behavior can be changed by the flag "disable_prefix", which is triggered by the parameter " use-host-decl-name".

By having this parameter set to "on", we remove the unexpected prepending from the dhcpd.conf file and therefore the hosts file gets updated with the correct name.

Welcome on board @CBRjack
@dmbaturin can we ship this on by default maybe ?

I prefer opt-in options over 'enable by proxy'.
use-host-decl-name [no-prefix]
and future get-lease-hostnames?

EwaldvanGeffen mentioned this in Unknown Object (Ponder Answer).Sep 26 2016, 10:34 PM

@EwaldvanGeffen so how this end up?
should i pick it up from you?

@UnicronNL we collected here all info,
do you think we can move that to backlog?

This required a little voting or some input by a core member on syntax. Once that's established implementation proceeds.

syncer changed the subtype of this task from "Task" to "Bug".Oct 18 2018, 5:52 AM
dmbaturin set Why the issue appeared? to Will be filled on close.
c-po edited projects, added VyOS 1.3 Equuleus; removed VyOS-1.2.0-GA.
c-po moved this task from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po changed Why the issue appeared? from Will be filled on close to Design mistake.
c-po removed a subscriber: VyOS 1.2 Crux.

@c-po should be in crux too

Hello, unfortunately this issue is not fully resolved (tested in Crux 1.2.1) because the name of the shared-network is still prepended to the hostname in /etc/hosts by It's hard-coded, but should be conditional to actually restore the old behaviour (before core rewrite), where (like @CBRjack described) a flag "disable_prefix" triggered by the "use-host-decl-name" option did prevent the old from prepending the shared-network-name.

This small patch to should do it:

--- /usr/libexec/vyos/conf_mode/	2019-04-12 16:14:20.000000000 +0200
+++ /usr/libexec/vyos/conf_mode/	2019-05-04 17:45:49.426975722 +0200
@@ -184,7 +184,7 @@
         {%- endif -%}
         {%- for host in subnet.static_mapping %}
         {% if not host.disabled -%}
-        host {{ }}_{{ }} {
+        host {% if host_decl_name -%} {{ }} {%- else -%} {{ }}_{{ }} {%- endif %} {
             fixed-address {{ host.ip_address }};
             hardware ethernet {{ host.mac_address }};
             {%- if host.static_parameters %}

I've tested the patch and it works as expected. All dhcp static-mappings in /etc/hosts are correct if use-host-decl-names on; is set.
How can I make a PR around here? :-) Thanks!


@krassle I added your patch. will be in next rolling release. thx

@c-po Still not fully resolved on Crux . Maybe candidate for Backlog on VyOS 1.2.3? Thanks.

richardpowellus added a subscriber: richardpowellus.

This issue seems to still be reproducing on static mappings with 1.2.5. I have noticed that the issue is fixed for non static mapping DHCP clients but all my clients who are getting assigned their IPs via static mappings are still getting their hostnames prefixed with LAN_ (LAN being my shared network name).

c-po changed the task status from Open to Needs testing.May 20 2020, 7:50 PM
c-po closed this task as Resolved.
c-po set Is it a breaking change? to Unspecified (possibly destroys the router).

@richardpowellus you could test it on an 1.2.5 system by running the following commands:

$ cd /tmp
$ wget
$ sudo dpkg -i vyos-1x_1.2.5_all.deb
erkin renamed this task from wrong hostnames in hosts file to DHCP server prepends shared network name to hostnames.Sep 5 2020, 12:04 PM