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

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

For part of hosts it add VoIP_? for part not. VoIP - is shared-network-name on DHCP.

10.11.3.6 VoIP_spa8000-2.voip.adriatika.local #on-dhcp-event 0:25:9c:6e:8:64
10.11.3.5 VoIP_spa8000-1.voip.adriatika.local #on-dhcp-event 20:aa:4b:57:f4:80
10.11.3.11 pool-adm-KX-HDV100RU.voip.adriatika.local #on-dhcp-event 8:0:23:e1:71:b

I didn't edit it.
That's it http://pastebin.com/8BcPLgkn

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?

http://pastebin.com/DHmPus8S

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

Update:
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
10.11.3.12 AdrSPA8000-3.voip.adriatika.local #on-dhcp-event d0:c7:89:78:fb:f0 - it was DHCP
10.11.3.7 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, any updates?

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 http://bugzilla.vyos.net/show_bug.cgi?id=334 / Reading into it.

@hexes
check this thread
https://www.reddit.com/r/homelab/comments/535fa6/vyos_dhcp_weirdness/d7q6e6g

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 dhcpd-config.pl 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 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.

@EwaldvanGeffen do poll if so

@c-po
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 dhcp_server.py. 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 dhcp-config.pl from prepending the shared-network-name.

This small patch to dhcp_server.py should do it:

--- /usr/libexec/vyos/conf_mode/dhcp_server.py.bak	2019-04-12 16:14:20.000000000 +0200
+++ /usr/libexec/vyos/conf_mode/dhcp_server.py	2019-05-04 17:45:49.426975722 +0200
@@ -184,7 +184,7 @@
         {%- endif -%}
         {%- for host in subnet.static_mapping %}
         {% if not host.disabled -%}
-        host {{ network.name }}_{{ host.name }} {
+        host {% if host_decl_name -%} {{ host.name }} {%- else -%} {{ network.name }}_{{ host.name }} {%- 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!

Cheers,
BBG

@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.

@krassle backported to crux branch

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

$ cd /tmp
$ wget http://dev.packages.vyos.net/repositories/crux/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.5_all.deb
$ sudo dpkg -i vyos-1x_1.2.5_all.deb