On 11/05/2017 14:36, Simon Kelley wrote:
> The design is that dnsmasq sends the options expected by a PXE client if
> it's acting as a proxy (because the whole proxy thing is part of the PXE
> spec: a normal DHCP client doesn't know how to deal with it.) The
> replies to the PXE client are constructed using the information given in
> the pxe-service and pxe-prompt options. The inclusion of arbitrary
> vendor-specific options is an oversight, I think.
> As the PXE-spec doesn't AFAIK, include root-path as an expected option,
> I'm not sure that sending it will have any effect.
> As stated in the thread you link to, if you're netbooting an OS via PXE
> then one the OS starts, it will do DHCP again, and that's the time to
> send arbitrary options.
> TL;DR I don't think implementing what you're asking for will achieve
> what you want, but if you can demonstrate that it will, then I'll
> certainly looking at adding the extra function.
thank you very much for reply.
My reason for wanting that feature is to support a scenario where is a main DHCP
server that is tasked only with giving out network information and which I can
not modify at all. In my opinion options like root-path, swap-server and
similar belong to the same league as, say, bootfile-name rather than, say,
dns-server or router. In either case, my main DHCP server is not configured to
Also, in my case it is the OS that wants to get root-path not the first stage
So, without dnsmasq allowing me to send root-path option there is no way I can
give it to the OS.
I thought that the purpose of the proxy mode was exactly to help with PXE / OS
booting in situations where the main DHCP server can not be altered to do that
Having said all of the above, I should admit that the OS in question could be
non-compliant with the PXE specification. Maybe it should use a different
mechanism like vendor options or a configuration file (advertised via
bootfile-name) to get the information it needs.
Dnsmasq-discuss mailing list