[Dnsmasq-discuss] specifying dhcp options in proxy mode

[Andriy Gapon]

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.

[Simon Kelley]

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.

Post by Andriy Gapon
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.
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2012q2/005722.html
Looks like the situation hasn't changed since then.

[Andriy Gapon]

Post by Simon Kelley
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.

Simon,

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
advertise root-path.

Also, in my case it is the OS that wants to get root-path not the first stage
PXE loader.

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 job.

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.

[Simon Kelley]

Post by Andriy Gapon

Post by Simon Kelley
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.

Simon,
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
advertise root-path.
Also, in my case it is the OS that wants to get root-path not the first stage
PXE loader.
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 job.
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.

To the best of my knowledge it's _only_ PXE clients which can accept
extra options from a proxy. PXE is a superset of DHCP, which includes
that functionality. The DHCP clients run by the OS are just that - DHCP
clients, they don't know how to do the PXE proxy-server tricks.


Cheers,

Simon.

[Andriy Gapon]

Post by Simon Kelley
To the best of my knowledge it's _only_ PXE clients which can accept
extra options from a proxy. PXE is a superset of DHCP, which includes
that functionality. The DHCP clients run by the OS are just that - DHCP
clients, they don't know how to do the PXE proxy-server tricks.

It seems that the discussion went into a direction that I didn't expect.

Let me try to make it simpler (for me) again.
So, should dnsmasq in the DHCP proxy mode be able to send a root-path option?

[Andriy Gapon]

Post by Andriy Gapon

Post by Simon Kelley
To the best of my knowledge it's _only_ PXE clients which can accept
extra options from a proxy. PXE is a superset of DHCP, which includes
that functionality. The DHCP clients run by the OS are just that - DHCP
clients, they don't know how to do the PXE proxy-server tricks.

It seems that the discussion went into a direction that I didn't expect.
Let me try to make it simpler (for me) again.
So, should dnsmasq in the DHCP proxy mode be able to send a root-path option?

No it can't. It's deliberate that it can't and the reasoning for that is
that packets sent in proxy mode can only go to a PXE client, which
doesn't know what to do with (eg) a root-path option.

As an example, iPXE does know what to do with root-path in certain cases:
http://ipxe.org/howto/dhcpd
http://ipxe.org/sanuri

As an aside, as far as I can see, iPXE never contacts the proxy server on the
proxy port. It takes all information it needs from the proxy's DHCP offer
packet and does not perform any further communication with it.

If that reasoning is shown to be incorrect, it would be relatively
simple to change the code to allow arbitrary options.

[Floris Bos]

Post by Simon Kelley
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.

Recall some operating systems like FreeBSD do not do DHCP again when net
booting, but obtain the cached packet from PXE using the GET_CACHED_INFO
PXE call.


Yours sincerely,

Floris Bos

[Floris Bos]

That actually made sense as the DHCP sever could be configured to provide
different information depending on the PXE client. That's how my environment is
setup: dnsmasq offers a menu of boot options (via pxe-service + pxe-prompt) to a
client that's built into network cards, but provides root-path, etc, to pxeboot.

That may work for some limited use-cases.
But I don't think it's a very good solution, as you can only have one
FreeBSD item in your menu that way, and not multiple with different
root-paths.

Think a better long term solution would be if some effort was made to
add support in iPXE to boot FreeBSD kernels directly without pxeboot,
and pass parameters to them, like is possible with Linux kernels.
Can then create a menu using an ipxe script.
iPXE's menu support is a lot more capable then the limited menu
functionality offered by normal PXE through dnsmasq.


Yours sincerely,

Floris Bos

[Floris Bos]

Post by Floris Bos

Post by Simon Kelley
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.

Recall some operating systems like FreeBSD do not do DHCP again when net
booting, but obtain the cached packet from PXE using the GET_CACHED_INFO
PXE call.

How does this handle the case that the PXE client has received _two_
packets, one from the DHCP server with an IP address, and one from a PXE
proxy server with netbbot information. Does GET_CACHED_INFO return one,
or both, or the combined information from both?

Can specify which packet you want to have. From the PXE spec:

==
Op-Code: PXENV_GET_CACHED_INFO (0071h)

Description: This service returns one of three buffers:
1. The client’s DHCPDISCOVER packet
2. The DHCP server’s DHCPACK packet
3. The Boot Server’s Discover Reply packet, which contains Option #60
set to “PXEClient”, a
valid boot file name, and may contain MTFTP options
==

Recall FreeBSD asks for 3.
So yes, I think that in theory it should work if the proxy DHCP packet
contains the NFS root-path.

The TS did not specify which operating system he is using though.
So don't know if it also works with his.


Yours sincerely,

Floris Bos