[Dnsmasq-discuss] Cannot send dhcp option 12 hostname to clients
Kevin Flynn
kevflynn69 at gmail.com
Wed May 15 17:10:29 BST 2019
On 5/15/19 10:56 AM, john doe wrote:
> On 5/15/2019 4:27 PM, Kevin Flynn wrote:
>> On 5/15/19 1:25 AM, Geert Stappers wrote:
>>> Share that dhcp-host lines with your audience here.
>>> Make it possible that they can verify how far they match
>>>>> "--dhcp-host=[<hwaddr>][,id:<client_id>|*][,set:<tag>][,<ipaddr>][,<hostname>][,<lease_time>][,ignore"
>>>>>
>>
>> From my /etc/dnsmasq/dhcp-lana.hosts file, in which all lines are
>> comments beginning with #, whitespace, or lines which resemble the
>> following:
>>
>> | xx:xx:xx:xx:xx:xx,192.168.100.101,phone1,12h
>> | xx:xx:xx:xx:xx:xx,192.168.100.102,phone2,12h
>> ... etc.
>>
>
>>From dnsmasq.conf:
>
> # Always give the host with Ethernet address 11:22:33:44:55:66
> # the name fred and IP address 192.168.0.60 and lease time 45 minutes
> #dhcp-host=11:22:33:44:55:66,fred,192.168.0.60,45m
>
> So 'MAC,hostname,IP,...' and not 'MAC,IP,hostname,...'.
>
> --
> John Doe
From the man page ( man dnsmasq ) on my system which is:
1) Manjaro 18 KDE ( kernel 4.19.28-1-MANJARO )
2) Dnsmasq version 2.80 ( dnsmasq --version )
| -G, --dhcp-host=[<hwaddr>][,id:<client_id>|*][,set:<tag>][,<ipaddr>][,<hostname>][,<lease_time>][,ignore]
As you can see, it shows the order to be "[,<ipaddr>][,<hostname>]"
As I initially stated, I have tried every possible combination of options mentioned in
the .conf file as well as the man page, and in the spirit of completeness, I just
attempted reversing the order to what you suggested, and verifying the response from
dnsmasq using both wireshark as well as the log-dhcp option, and dnsmasq still does not
send the hostname to the client.
At the very least, we seem to have discovered a discrepency between what the example .conf
file states is the correct order, and what the man page states is the correct order.
I have many decades of IT experience, and as I originally stated, I have tried every possible
combination, and spent hours of time before posting here, and I do not believe this to be some
sort of obvious user error at this point, so the likelyhood that blind guessing is going to
discover a solution is low in my opinion. I am of course human, and I do make mistakes, which
is where a working validated example would be helpful.
If someone out there has a working configuration that satisfies the following criteria I would
be more than happy to attempt it here on my end. The criteria is as follows:
1) The client sends a hostname in its request
2) The client does not request option 12 in its parameter request list
3) Dnsmasq successfully sends a hostname response which overrides the hostname sent by the
client. ( the client of course is free to ignore the new hostname, but the point here is
that dnsmasq sends a hostname different than the one sent in the client request when
the client has not requested it in the parameter list )
Kevin Flynn
More information about the Dnsmasq-discuss
mailing list