[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