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. Cheers, Simon. On 10/05/17 14:32, Andriy Gapon wrote: > > It seems that present dnsmasq adds only vendor-specific option when it > operates > on the proxy mode. > E.g., with a config that has > dhcp-range=192.168.0.88,proxy,255.255.255.0 > dhcp-option=vendor:PXEClient,6,2b > dnsmasq adds option 43, suboption 6 to its responses. > > But if I have > dhcp-range=192.168.0.88,proxy,255.255.255.0 > dhcp-option=option:root-path,"192.168.0.200:/export/netboot" > then the root-path option is not set in the responses. > That's the case even if I use dhcp-option-force. > > Is there any reason for this? > Could dnsmasq be changed to allow explicitly set options for proxy responses? > I think that that would add more flexibility for users who know what they are > doing. > > P.S. > I found this old conversation: > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2012q2/005722.html > Looks like the situation hasn't changed since then. >
Description: OpenPGP digital signature
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasqfirstname.lastname@example.org http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss