Page MenuHomePhabricator

wrong hostnames in hosts file
Closed, ResolvedPublicBUG

Description

root@vyos:~# cat /etc/hosts
127.0.0.1 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
127.0.1.1        vyos.adriatika.local vyos       #vyatta entry

10.11.3.3        VoIP_PanasonicNCP500_IPCMPR.voip.adriatika.local        #on-dhcp-event 0:80:f0:d1:6c:f6
10.11.3.2        VoIP_IPPBX.voip.adriatika.local         #on-dhcp-event 0:c:29:32:9d:6c

why it add "VoIP_" in front of hostname?

Details

Difficulty level
Normal (likely a few hours)
Version
VyOS 1.2.0-beta1
Why the issue appeared?
Design mistake
hexes created this task.Jul 13 2016, 5:25 AM

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

syncer claimed this task.Jul 13 2016, 8:14 AM
syncer closed this task as Invalid.
syncer triaged this task as Low priority.
syncer added a subscriber: syncer.

Hello,
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
Thanks!

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

syncer reopened this task as Open.Jul 14 2016, 10:59 AM
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?

hexes added a comment.Jul 18 2016, 4:00 AM

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

hexes added a comment.Jul 18 2016, 9:21 AM

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

hexes added a comment.Jul 19 2016, 4:15 AM

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

hexes added a comment.Aug 31 2016, 4:47 AM

Hello, any updates?

syncer reassigned this task from syncer to EwaldvanGeffen.Aug 31 2016, 10:42 PM

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

EwaldvanGeffen added a comment.EditedSep 1 2016, 11:40 PM

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

hexes added a comment.Sep 12 2016, 8:29 AM
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.

EwaldvanGeffen added a comment.EditedSep 15 2016, 5:32 PM

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 mentioned this in Unknown Object (Ponder Answer).Sep 26 2016, 10:34 PM
syncer added a subscriber: VyOS 1.2 Crux.
syncer added a comment.Aug 1 2017, 2:35 AM

@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 changed the task status from Open to In progress.Aug 12 2017, 5:16 PM
pasik added a subscriber: pasik.Oct 1 2018, 9:55 AM
syncer reassigned this task from EwaldvanGeffen to c-po.Oct 13 2018, 10:11 AM
syncer edited projects, added VyOS 1.2 Crux (VyOS 1.2.0-rc4); removed VyOS 1.2 Crux.
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 moved this task from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po closed this task as Resolved.
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.
syncer reopened this task as In progress.

@c-po should be in crux too

c-po closed this task as Resolved.Mar 17 2019, 2:58 PM