[Dnsmasq-discuss] Small dnsmasq 2.22 issue

[Ron Frederick]

Hi Simon...

In message <42B456D9.7030304@thekelleys.org.uk> you write:
> Ron Frederick wrote:
>> I recently started the "dnsmasq" program as part of the OpenWRT
>> distribution on my Linksys WRT54GS wireless router. It replaced an ISC
>> 'dhcpd' I was running on a desktop Linux machine. However, I ran into
>> one problem when I switched over. I noticed that the DHCP OFFER responses
>> were no longer including the DHCP 'host-name' option. This option was
>> included in DHCP ACK responses to the same host later on, but it was
>> missing from the initial OFFER response. I have a Rio Digital Audio
>> Receiver here which depends on seeing the hostname in the OFFER response
>> to boot properly. So, I took a look at the source code to see if I could
>> find the problem.
>> 
>> It turned out to be quite straightforward to fix it. All I had to do was
>> to change the call to do_req_options() in the OFFER case to pass 'hostname'
>> as an argument instead of NULL, just as is done later when sending the ACK.
>> I'm not sure if there was a specific reason why the hostname was omitted
>> from the OFFER response, but the ISC dhcpd does include it and as I
>> mentioned above my Rio seemed to require it.
> 
> I honestly can't find for sure any reason why the hostname isn't sent in 
> a DHCP offer. It never has been, in any version way back to 2.0, the 
> first to include an DHCP server. I guess this effect has never come up 
> before. (DHCP is a madenningly under-specified protocol: the de-facto 
> spec seems to be "What the ISC server does", hence  these interesting 
> corner cases.)
> 
Yes - I've noticed this... I suspect most hosts either ignore the received
hostname or will pick it up from the ACK if they do use it, so this case
probably won't affect them. It affected the Rio only because it actually used
the hostname to decide where to NFS mount its root filesystem from during
the initial boot process. It would fall back on using its IP address if the
hostname wasn't present, so I was able to make it work even without this
patch, but as I renumbered things I had to keep remembering to change around
where I put its root filesystem on my NFS server, and it was easier to just
have it always mount it with the same name.

> I have a very vague memory about not sending a different hostname to one 
> supplied in a DHCPDISCOVER, in case the offer is rejected due to the 
> name mismatch, but I can't remember if that was based on a real problem, 
> or a guess on my part that it might be. In any case, it only applies 
> when the client sends one hostname, and dnsmasq overides it with a 
> different one.
> 
> I think the best thing would probably be to elaborate your patch to 
> continue the current behaviour when dnsmasq overrides a hostname sent in 
> DHCPDISCOVER, but otherwise to always include the configured hostname.
> 
> I'll do a test release with that behaviour over the weekend.
> 
Yeah - that makes sense. I noticed some code in the other code path that
seemed to special-case the hostname option. It would be good to make sure
that the hostname presented in the OFFER is the same as what eventually
appears in the ACK. I'd be happy to try out your patch if you want some
additional testing of it.

Thanks very much for your quick response, and for the great tool!
--
Ron Frederick
frederick@timeheart.net