Discussion:
[Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents
Dreamcat4
2016-05-05 19:26:36 UTC
Permalink
Hi there,
Was hit by this undocumented bug in dnsmasq today / yesterday. It took a
fair whilefor me to realize this was the cause of my problem. But now
finally here! Coming across this list, and several threads in it, Michael
has kindly posted a patch to help get PXE working for UEFI clients:

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/010007.html

So today checked out the dnsmasq source code in git, and see this patch is
still missing / not applied. Therefore the bug remains in HEAD.

So since then further searching, has unturned more affected people(s), on
here:

http://serverfault.com/questions/758384/dnsmasq-proxy-mode-and-efi-boot

And to breifly highlight one of those guys' comments, in hopes it might be
relevant to finding best solution possible. Michael can you comment? As it
was written about after you already made your last patch.

"I have read the whole thread (
lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/

<http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/009907.html>)
and I'm shocked; those guys are completely lost; UEFI perfectly supports
proxyDHCP w/o using option 60, also using option 43 when not necessary
makes no sense. If I were I'd look away from dnsmasq; Sorry I didn't know
they were having this kind of unresolved problems. – Pat
<http://serverfault.com/users/133655/pat> Feb 20 at 14:59
<http://serverfault.com/questions/758384/dnsmasq-proxy-mode-and-efi-boot#comment953297_758418>
(2016)"

Reading that, I do wonder where he got his information from. It seems to
suggest maybe there exists some working windows PXE server(s). Which work
in proxyDHCP mode for UEFI pxe clients. Something that could be wiresharked
/ pcap tcpdump'd.

Anyhow, unfortunately it doesnt seem theres any alternative to dnsmasq on
linux, for acting as a proxy DHCP server. At least not that I know of.
Several other answers on StackOverflow seem to confirm that view:

http://serverfault.com/questions/415857/can-isc-dhcpd-operate-as-a-proxy-dhcp-server-for-pxe-boot


So assuming that dnsmasq is still our best shot here, and that UEFI
compatibility its becoming much more common now, can we please look again
at michaels patch for inclusion? Or else have this known bug (of proxy
mode) documented in the man page? Would really appreciate that. Many thanks.



Dreamcat4
Dreamcat4
2016-05-05 22:58:26 UTC
Permalink
In the meantime,

Have setup an auto-builds. To make linux binary tarball of last released
version. In debian / ubunt filesystem layout.

Added with the necessary (but missing) uefi patch ^^ from Micahael


Its built here:

https://github.com/dreamcat4/docker-images/blob/master/linux-bin/Dockerfile#L26-63



Binary is available here:

https://dl.bintray.com/dreamcat4/linux/dnsmasq/


Haven't tested it for myself yet. (but will try soon). Hope it works.


Kind Regards
Dreamcat4
Post by Dreamcat4
Hi there,
Was hit by this undocumented bug in dnsmasq today / yesterday. It took a
fair whilefor me to realize this was the cause of my problem. But now
finally here! Coming across this list, and several threads in it, Michael
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/010007.html
So today checked out the dnsmasq source code in git, and see this patch is
still missing / not applied. Therefore the bug remains in HEAD.
So since then further searching, has unturned more affected people(s), on
http://serverfault.com/questions/758384/dnsmasq-proxy-mode-and-efi-boot
And to breifly highlight one of those guys' comments, in hopes it might be
relevant to finding best solution possible. Michael can you comment? As it
was written about after you already made your last patch.
"I have read the whole thread (
lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/

<http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/009907.html>)
and I'm shocked; those guys are completely lost; UEFI perfectly supports
proxyDHCP w/o using option 60, also using option 43 when not necessary
makes no sense. If I were I'd look away from dnsmasq; Sorry I didn't know
they were having this kind of unresolved problems. – Pat
<http://serverfault.com/users/133655/pat> Feb 20 at 14:59
<http://serverfault.com/questions/758384/dnsmasq-proxy-mode-and-efi-boot#comment953297_758418>
(2016)"
Reading that, I do wonder where he got his information from. It seems to
suggest maybe there exists some working windows PXE server(s). Which work
in proxyDHCP mode for UEFI pxe clients. Something that could be wiresharked
/ pcap tcpdump'd.
Anyhow, unfortunately it doesnt seem theres any alternative to dnsmasq on
linux, for acting as a proxy DHCP server. At least not that I know of.
http://serverfault.com/questions/415857/can-isc-dhcpd-operate-as-a-proxy-dhcp-server-for-pxe-boot
So assuming that dnsmasq is still our best shot here, and that UEFI
compatibility its becoming much more common now, can we please look again
at michaels patch for inclusion? Or else have this known bug (of proxy
mode) documented in the man page? Would really appreciate that. Many thanks.
Dreamcat4
Dreamcat4
2016-05-06 10:40:57 UTC
Permalink
OK,
So I have 2 UEFI PCs. And today tested the patch. It worked! Very happy
about this.

I encourage other people to try it too, now the patched binary is available
from my bintray repo here:

https://dl.bintray.com/dreamcat4/linux/dnsmasq/

In coming days shall also be releasing a 'dreamcat4/pxe' docker image,
which will contain it + other necessary configuration / setup files for
serving up iPXE in both modes (legacy AND uefi). That is just not ready yet.

For this patch, I can only test in ProxyDHCP mode. Due to my other
technical limitations of available hardware / servers etc.

In proxy mode, this patch:

a) greatly improves the functionality of UEFI pxe booting, from nothing
(0%) --> to 'usable'
b) does not break the existing legacy BIOS pxe booting. both types can be
served simultaneously.

Was tested with iPXE pre-built binaries downloaded from iPXE website. They
were:


[image: [ ]]undionly.kpxe <http://boot.ipxe.org/undionly.kpxe>06-May-2016
11:00 63K

[image: [ ]]ipxe.efi <http://boot.ipxe.org/ipxe.efi>06-May-2016 11:00 888K




Those observations seem to agree / confirm Michael's own findings about
about his last patch (of oct-31-2015). And what is mentioned bout iPXE.efi
on the iPXE website. For example that in UEFI mode, there is some
considerable delay, waiting about, where it says:

iPXE initialising devices....

but then it eventually finds / goes into the menu. Perhaps with help of the
user pressing 'enter' key if stuck. So not perfect. But can be made to work.

Simon to pls take a look at this patch, be sight-checked for errors / risks
(anything amiss?), then if nothing bad found, pls consider adding to head
for next 'testing' tag future releases. That would be priceless. Appreciate
it.


Perhaps later down the line (once more people get onboard and can start
using it), then this pxe UEFI mode can be improved even further. Either buy
some fresh eyes coming along to fix problems in ipxe.efi, or else here in
the dnsmasq behaviour. Or both. But we need to make it easier for those
guys to run it at least, so can see ahead to the next problem. Many thanks.


Dreamcat4
Post by Dreamcat4
In the meantime,
Have setup an auto-builds. To make linux binary tarball of last released
version. In debian / ubunt filesystem layout.
Added with the necessary (but missing) uefi patch ^^ from Micahael
https://github.com/dreamcat4/docker-images/blob/master/linux-bin/Dockerfile#L26-63
https://dl.bintray.com/dreamcat4/linux/dnsmasq/
Haven't tested it for myself yet. (but will try soon). Hope it works.
Kind Regards
Dreamcat4
Post by Dreamcat4
Hi there,
Was hit by this undocumented bug in dnsmasq today / yesterday. It took a
fair whilefor me to realize this was the cause of my problem. But now
finally here! Coming across this list, and several threads in it, Michael
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/010007.html
So today checked out the dnsmasq source code in git, and see this patch
is still missing / not applied. Therefore the bug remains in HEAD.
So since then further searching, has unturned more affected people(s), on
http://serverfault.com/questions/758384/dnsmasq-proxy-mode-and-efi-boot
And to breifly highlight one of those guys' comments, in hopes it might
be relevant to finding best solution possible. Michael can you comment? As
it was written about after you already made your last patch.
"I have read the whole thread (
lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/

<http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/009907.html>)
and I'm shocked; those guys are completely lost; UEFI perfectly supports
proxyDHCP w/o using option 60, also using option 43 when not necessary
makes no sense. If I were I'd look away from dnsmasq; Sorry I didn't know
they were having this kind of unresolved problems. – Pat
<http://serverfault.com/users/133655/pat> Feb 20 at 14:59
<http://serverfault.com/questions/758384/dnsmasq-proxy-mode-and-efi-boot#comment953297_758418>
(2016)"
Reading that, I do wonder where he got his information from. It seems to
suggest maybe there exists some working windows PXE server(s). Which work
in proxyDHCP mode for UEFI pxe clients. Something that could be wiresharked
/ pcap tcpdump'd.
Anyhow, unfortunately it doesnt seem theres any alternative to dnsmasq on
linux, for acting as a proxy DHCP server. At least not that I know of.
http://serverfault.com/questions/415857/can-isc-dhcpd-operate-as-a-proxy-dhcp-server-for-pxe-boot
So assuming that dnsmasq is still our best shot here, and that UEFI
compatibility its becoming much more common now, can we please look again
at michaels patch for inclusion? Or else have this known bug (of proxy
mode) documented in the man page? Would really appreciate that. Many thanks.
Dreamcat4
Jaroslaw Polok
2016-05-06 11:58:30 UTC
Permalink
Hi
Post by Dreamcat4
Perhaps later down the line (once more people get onboard and can start
using it), then this pxe UEFI mode can be improved even further. Either
buy some fresh eyes coming along to fix problems in ipxe.efi, or else
here in the dnsmasq behaviour. Or both. But we need to make it easier
for those guys to run it at least, so can see ahead to the next problem.
In case you would be interested:

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010383.html

That is my version of the patch, using a configuration option
to allow more fine-grained control on how systems boot
(by optionally matching by tag and/or architecture).

We are using that patch in production since two months
successfully booting all PXE/UEFI systems (x64 and aarch64)
we have used so far (about 10 different x64 and 3 different
aarch64 systems, plus qemu-kvm with Tianocore firmware)

Dear Simon: would it be possible to review and include one
of this patches in dnsmasq please ?

Thanks

Jarek
Dreamcat4
2016-05-06 21:51:28 UTC
Permalink
Thanks Jarek!

Have tried your patch and switched to it in my auto builds now. Same
Bintray download URL as before:

https://dl.bintray.com/dreamcat4/linux/dnsmasq/

Re-formatted it so the patch will apply cleanly on v2.75 current release
version. Which is available here:

https://github.com/dreamcat4/docker-images/blob/master/linux-bin/dnsmasq/fix--dhcp-proxy-for-uefi-clients_02-mar-2016_jpolok.patch

The reason am using your patch now, is since you say it will be compatible
with more other uefi clients. So that is more good news to me. However it
is now necessary to add the following extra lines to dnsmasq.conf file.
Which is about this new option you added (skip menu). Otherwise uefi pxe
boot wont work at all. Like back to old days, where it just hangs, does
nothing like without any such uefi patch.

New lines to add to dnsmasq.conf:

pxe-skip-menu=X86-64_EFI
pxe-skip-menu=BC_EFI

The 2nd line was added for better compatibility (after other reports of
misbehaving clients), which is mentioned by David on other thread:

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q4/010041.html


Anyway then it loads up the ipxe.efi. BTW, sorry for not being clear in my
previous mesg but the version of ipxe.efi have been testing with today is
v1.0.0+ (2d42d).

This lets me get forward enough to be encountering other bugs arounds
netbooting uefi. But those other new issue I am seeing now is nothing
related to dnsmasq itself. As that has finished / done its job by time of
those stages in the boot process.


Kind Regards
Dreamcat4
Post by Jaroslaw Polok
Hi
Post by Dreamcat4
Perhaps later down the line (once more people get onboard and can start
using it), then this pxe UEFI mode can be improved even further. Either
buy some fresh eyes coming along to fix problems in ipxe.efi, or else
here in the dnsmasq behaviour. Or both. But we need to make it easier
for those guys to run it at least, so can see ahead to the next problem.
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010383.html
That is my version of the patch, using a configuration option
to allow more fine-grained control on how systems boot
(by optionally matching by tag and/or architecture).
We are using that patch in production since two months
successfully booting all PXE/UEFI systems (x64 and aarch64)
we have used so far (about 10 different x64 and 3 different
aarch64 systems, plus qemu-kvm with Tianocore firmware)
Dear Simon: would it be possible to review and include one
of this patches in dnsmasq please ?
Thanks
Jarek
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Simon Kelley
2016-05-07 20:49:44 UTC
Permalink
Post by Jaroslaw Polok
Hi
Post by Dreamcat4
Perhaps later down the line (once more people get onboard and can start
using it), then this pxe UEFI mode can be improved even further. Either
buy some fresh eyes coming along to fix problems in ipxe.efi, or else
here in the dnsmasq behaviour. Or both. But we need to make it easier
for those guys to run it at least, so can see ahead to the next problem.
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010383.html
That is my version of the patch, using a configuration option
to allow more fine-grained control on how systems boot
(by optionally matching by tag and/or architecture).
We are using that patch in production since two months
successfully booting all PXE/UEFI systems (x64 and aarch64)
we have used so far (about 10 different x64 and 3 different
aarch64 systems, plus qemu-kvm with Tianocore firmware)
Dear Simon: would it be possible to review and include one
of this patches in dnsmasq please ?
Yes, That's the last thing on my list to do before I start to release
2.76. You and Dreamcat are going to have to help me though, since I
don't have a usable test environment for this stuff, and my PXE
knowledge is buried under several years of other stuff.


My main question is, is there a way to make this work without needing
the --pxe-skip-menu option. I appreciate that this engages a workaround
for buggy UEFI netboot implementations, but what's wrong with doing that
automatically when there's only one possible boot? Are we loosing
functionality (maybe with a hypothetical fully working BIOS) by doing that?


Cheers,

Simon.
Dreamcat4
2016-05-08 10:52:48 UTC
Permalink
Post by Jaroslaw Polok
Post by Jaroslaw Polok
Hi
Post by Dreamcat4
Perhaps later down the line (once more people get onboard and can start
using it), then this pxe UEFI mode can be improved even further. Either
buy some fresh eyes coming along to fix problems in ipxe.efi, or else
here in the dnsmasq behaviour. Or both. But we need to make it easier
for those guys to run it at least, so can see ahead to the next problem.
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010383.html
Post by Jaroslaw Polok
That is my version of the patch, using a configuration option
to allow more fine-grained control on how systems boot
(by optionally matching by tag and/or architecture).
We are using that patch in production since two months
successfully booting all PXE/UEFI systems (x64 and aarch64)
we have used so far (about 10 different x64 and 3 different
aarch64 systems, plus qemu-kvm with Tianocore firmware)
Dear Simon: would it be possible to review and include one
of this patches in dnsmasq please ?
Yes, That's the last thing on my list to do before I start to release
2.76. You and Dreamcat are going to have to help me though, since I
don't have a usable test environment for this stuff, and my PXE
knowledge is buried under several years of other stuff.
No problem, happy to help.

My main question is, is there a way to make this work without needing
Post by Jaroslaw Polok
the --pxe-skip-menu option. I appreciate that this engages a workaround
for buggy UEFI netboot implementations, but what's wrong with doing that
automatically when there's only one possible boot?
Yeah I was thinking that too. But then I looked more carefully at Jarek's
patch this morning. And it gets me to understanding why he made the option
that way around.

It is a lot to do with how-to-set-options in dnsmasq (the options
conventions of your program).
Post by Jaroslaw Polok
Are we loosing
functionality (maybe with a hypothetical fully working BIOS) by doing that?
OK lets start with what we know:

pxe-skip-menu=X86-64_EFI
pxe-skip-menu=BC_EFI

is the best thing to cover all of the regular PC users. Which is nearly
everybody. That is great.


====
Now lets imagine we take away the option. So there is no exposed option
whatsoever. New Drawback:

we cannot accomodate the situation where there are different behaving
clients identifying under a single CSA type. Which seems to be the case
(already known) for BC_EFI.

http://serverfault.com/questions/349693/pxe-architecture-bc-efi

What that link says ^^ is that BC_EFI is a non-descript (generic) client.
Which may be odd ones, like an old PowerPC mac or IBM PowerPC server. Or
equally it could be some early x86 UEFI client. That is a potential to need
to be flipped on/off a case-by-case basis. Depending upon the specific set
of client hardware models which exist at that site.

It may be true or false for lesser CSA types too. (depending the model of
hardware). 2nd example I can think of now is ARM64 uefi. Because IPXE
project just added support for ARM64 efi booting. For devices like rPi /
similar - very popular now. Don't see it listed as a CSA named type. Maybe
its going to identify as some new (higher) CSA number. Else re-use again
that generic catchall BC_EFI (yet again).

That is why I think having some kind of a user setting might be worth it.
For best comptibility to all users. We cannot be expected to know / test
all possible hardware. And there are many types of speciality devices /
quirky hardware.

But it is bad for each UEFI pc users going forwards to know to need to
manually specify:

pxe-skip-menu=X86-64_EFI
pxe-skip-menu=BC_EFI

Every time around. Because that is nearly everybody going forwards. How to
solve? Can we then make the option logic work better?

===
What about this idea:


Solution Part a)

Modify existing patch, make it a single string list of all CSAs for doing
pxe-skip-menu.

* Default value:

pxe-skip-menu="X86-64_EFI, BC_EFI".

* So if user says nothing, it 'just works'. If its wrong, simple for other
guys to come along later, tell us to update the setting ^^. Like to add
another one etc.

* User can overide it however they wish. To cover any quirky hardware they
might have (including to omit the troublesom BC_EFI on a per-user basis):

pxe-skip-menu="<CSA1>,<CSA2>"


Solution Part b)

Add in to the man page a clear paragraph, saying what is the SYMPTOM (of a
UEFI hanging boot). Which is exactly why / when the user should be setting
this option to override the mask list of CSAs.
Post by Jaroslaw Polok
Cheers,
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
w***@gmail.com
2016-05-08 14:41:50 UTC
Permalink
Post by Dreamcat4
But it is bad for each UEFI pc users going forwards to know to need to
pxe-skip-menu=X86-64_EFI
pxe-skip-menu=BC_EFI
Every time around. Because that is nearly everybody going forwards. How to
solve? Can we then make the option logic work better?
how about going the other way... reverse the logic so that those two are skipped
all the time... then only if they are needed, add an option to enable them...

pxe-add-menu=X86-64_EFI
pxe-add-menu=BC_EFI

in this manner, ONLY those that need to support the above UEFI mess need add the
option(s)... everyone else sails on clean clear waters none the wiser ;)

if other UEFIs are found needing to be skipped, they can be added to the next
binary with new options like the above...
--
NOTE: No off-list assistance is given without prior approval.
*Please keep mailing list traffic on the list* unless
private contact is specifically requested and granted.
Dreamcat4
2016-05-08 16:32:46 UTC
Permalink
Post by w***@gmail.com
how about going the other way... reverse the logic so that those two are
skipped all the time... then only if they are needed, add an option to
enable them...
pxe-add-menu=X86-64_EFI
pxe-add-menu=BC_EFI
Yeah that is not an unwelcome suggestion. Actually I was originally going
to say that same thing myself. Unfortunately, looking more closely a
similar type of problems comes up with doing it like that (either way
around).

AFAIKT...

people should only need to care / override this option if the client is
mis-behaving (client cannot show menu / hangs on menu / is buggy). So doing
a positive logic (pxe-add-menu=) is also not elegant. In fact, then there
may be even more default cases to specify and set. (a majority of working
clients).

Well if we must hard-code some behaviour, then for the fewest exception
cases is better, no? Well that seems to be for skip (not add). Because
people come here scratching out heads why pxe menu does not work for UEFI
clients. That is why skip-menu direction was chosen by Jarek. Perhaps
others can comment.


Anyhow regardless whether the direction is add or skip... that is apart
from my previous question. Which is:

Is it not best? (and simplest!) to modify Jarek's patch in this following
ways:

pxe-skip-menu="<CSA1>,<CSA2>,etc"

With a quiet *default* setting of:

pxe-skip-menu="X86-64_EFI,BC_EFI"

+ document it.


That user can clear with:

pxe-skip-menu=""

If they ever need.



Instead of:

pxe-skip-menu=CSA1
pxe-skip-menu=CSA2

Or:

pxe-add-menu=PC-DOS

Many thanks.



Kind Regards
Dreamcat4
Simon Kelley
2016-05-08 21:15:02 UTC
Permalink
I don't think that doing bug work-around behavior automagically is a
good idea. If it is required to do non-standard stuff, that should be
explicit.

The difference between Michael's patch and Jarek's seems to be that
Michael's works automatically when there is precisely one valid boot
service line, but Jarek's needs explicit configuration. What situation
does Jarek's approach cover, that Michael's doesn't?

Second question:

Michael's path sets the boot filename to <name>.efi rather than <name>.0
when the CSA is "IA32_EFI", "BC_EFI", "Xscale_EFI", or "x86-64_EFI" but
Jarek's doesn't. Should that be added to Jarek's patch?

Sorry if these seem like stupid questions. I'm working blind here,
without a test system to experiment with.


Cheers,

Simon.
Post by Dreamcat4
Post by w***@gmail.com
how about going the other way... reverse the logic so that those two are
skipped all the time... then only if they are needed, add an option to
enable them...
pxe-add-menu=X86-64_EFI
pxe-add-menu=BC_EFI
Yeah that is not an unwelcome suggestion. Actually I was originally going
to say that same thing myself. Unfortunately, looking more closely a
similar type of problems comes up with doing it like that (either way
around).
AFAIKT...
people should only need to care / override this option if the client is
mis-behaving (client cannot show menu / hangs on menu / is buggy). So doing
a positive logic (pxe-add-menu=) is also not elegant. In fact, then there
may be even more default cases to specify and set. (a majority of working
clients).
Well if we must hard-code some behaviour, then for the fewest exception
cases is better, no? Well that seems to be for skip (not add). Because
people come here scratching out heads why pxe menu does not work for UEFI
clients. That is why skip-menu direction was chosen by Jarek. Perhaps
others can comment.
Anyhow regardless whether the direction is add or skip... that is apart
Is it not best? (and simplest!) to modify Jarek's patch in this following
pxe-skip-menu="<CSA1>,<CSA2>,etc"
pxe-skip-menu="X86-64_EFI,BC_EFI"
+ document it.
pxe-skip-menu=""
If they ever need.
pxe-skip-menu=CSA1
pxe-skip-menu=CSA2
pxe-add-menu=PC-DOS
Many thanks.
Kind Regards
Dreamcat4
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Michael Kuron
2016-05-09 08:34:04 UTC
Permalink
Post by Simon Kelley
The difference between Michael's patch and Jarek's seems to be that
Michael's works automatically when there is precisely one valid boot
service line, but Jarek's needs explicit configuration. What situation
does Jarek's approach cover, that Michael's doesn’t?
I’ve also been wondering about that. Comparing the patches, I believe that, when skipping the menu, the only difference is that Jarek additionally sets the sname field, while I only set siaddr and file. I think Jarek said that without sname, some of his clients didn’t boot. I think it would be fine to add the sname line to my patch and hopefully that should fix Jarek’s clients too without needing all that pxe_skip_menu code.
Post by Simon Kelley
Michael's path sets the boot filename to <name>.efi rather than <name>.0
when the CSA is "IA32_EFI", "BC_EFI", "Xscale_EFI", or "x86-64_EFI" but
Jarek's doesn't. Should that be added to Jarek's patch?
Absolutely. <name>.0 is correct for x86 BIOS and <name>.efi is correct for EFI on any platform. Not sure about other (less common) platforms, but the current <name>.<numeric ID> is probably not right for anything except x86 BIOS.
Post by Simon Kelley
Sorry if these seem like stupid questions. I'm working blind here,
without a test system to experiment with.
If you have access to a recent version of VMware, I can send you a VMX file and an EFI binary for testing.

Michael
Jarek Polok
2016-05-09 09:27:44 UTC
Permalink
Hello all, (and sorry for top-posting, but trying to catch up with this
thread)

Since I believe that you already described what I had in mind in my
version of the patch ;-) I'll like to just add few comments on remaining
points:

Simon:

yes of course that would be possible to skip the option 'pxe-skip-menu'
alltogether: but


- I think that this is just a workaround (because what
dnsmasq implements should be working for PXE/UEFI ...)
and it may not be needed in the future .. so kind more 'elegant' to
implement it this way (option could be called 'pxe-menu-workaround'
perhaps ?

- It gives more flexibility: the workaround can be applied only
to predefined <tag> and <CSA> (sorry - patched man page should be
improved to state that clearly): so we can use that to implement
for example sthg like this:

- match on given hwaddr prefix with dhcp-match, then tag
- match on tag and client architecture and apply workaround only
then.


I think the 'tagging' capability of dnsmasq is rather nice feature
and should not be removed for this kind of workaround...


Dreamcat4:

Yes, the option could take multiple arguments:

pxe-skip-menu="TAG1,CSA1,TAG2,CSA2" .. etc (tags being optional)..
not sure that this is more readable than having the option specified
multiple times ... (but have no strong opinion about that ..)

I think that explaining in man page as you proposed - should be enough ..


wkitty42/Dreamcat4/Simon:

I also think that a workaround would better not be enabled by default,
just used when really needed.


Michael/Simon:

- setting of sname is indeed because I found 2 clients which did not
want to boot without it ..

- naming convention:

<name>.0 vs. <name>.efi - (I believe that I actually added .0 for efi
there): I think this is just convention (I believe initial idea was
that boot rom will be able to recognize the boot loader executable
format by extension and act accordingly to run it ... but I dont
think this really matters in current implementations .. for example
the Windows Deployment Server serves an .com or .exe or .efi this
days ...)

I think that actually the fact that dnsmasq adds '.0' for x86PC
is little bit confusing (yeah, I know its documented ..): and I
think that maybe it would be better not to add anything
'automagically' there .. but of course that would break backwards
compatibility ...

Then this will be confusing even more if sometimes .0
and sometimes .efi is added, as an example:

pxe-service=tag:TAG1,x86PC, "a", /path/loader
pxe-service=tag:TAG2,X86-64_EFI, "a" , /path/loader

first line would send /path/loader.0
second would send /path/loader.efi

So my personal opinion would be that adding no suffix
at all would be better ..

...

OK, so there are my 0.02EUR, thanks everybody !

Best Regards

Jarek


__
-------------------------------------------------------
_ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _
_ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _
______________________________________+41_75_411_9487 _
Michael Kuron
2016-05-09 12:24:59 UTC
Permalink
Post by Jarek Polok
- I think that this is just a workaround (because what
dnsmasq implements should be working for PXE/UEFI ...)
and it may not be needed in the future .. so kind more 'elegant' to
implement it this way (option could be called 'pxe-menu-workaround'
perhaps ?
This workaround will be required for at least a decade to come, as many current UEFI implementation still don’t correctly implement menus. So 99% of setups would need to enable the workaround, which means it should be default to avoid confusion.
Also, what’s wrong with disabling the menu if there is only one entry for the architecture, like my patch does? It doesn’t reduce functionality in any way and reduces the number of configuration options needed in the most common scenarios.
Post by Jarek Polok
- It gives more flexibility: the workaround can be applied only
to predefined <tag> and <CSA> (sorry - patched man page should be
improved to state that clearly): so we can use that to implement
- match on given hwaddr prefix with dhcp-match, then tag
- match on tag and client architecture and apply workaround only
then.
You can also use tags with my patch and achieve the same thing. For example, if you want clients with tag abcd to display a menu with two entries and all other clients to boot directly to the first entry (which for them is the only entry, thus invoking my workaround), you should be able to use something like
pxe-service=BC_EFI,iPXE,pxelinux
pxe-service=tag:abcd,BC_EFI,iPXE,ipxe
Post by Jarek Polok
- setting of sname is indeed because I found 2 clients which did not
want to boot without it ..
Ok, then I suggest we add that to my patch.
Post by Jarek Polok
<name>.0 vs. <name>.efi
The <name>.0 for X86PC can’t be changed due to backwards compatibility, otherwise everybody would have to update their config files. I’d be ok with not automatically adding an extension for all other architectures though. However, that would be inconsistent and also backwards-incompatible, though I wouldn’t worry too much about the latter as googling for "pxe-service=..." does not yield any meaningful hits for anything but x86PC, IA32_EFI, BC_EFI and X86-64_EFI.

Michael
Simon Kelley
2016-05-10 14:55:34 UTC
Permalink
Lots of good info. Thanks everybody. Some more queries.

First, I'm minded to go with Michael's choice for "enabling"
workarounds; ie do what's needed to make things work with buggy PXe
menu's when there's exactly one relevant menu entry.

Second,

<name>.0 vs. <name>.efi

What's not been mentioned here is that the 0-suffix is actually a
integer. There's a field in the pxe-boot-item called "layer" and that's
what's used to make the suffix. That could be any number less that 2^15.
What the function of this is seems to somewhat lost on time:

ftp://download.intel.com/design/archives/wfm/downloads/pxespec.pdf

says

This option is required to discover Boot Servers. Only the client
may change the type field; either the client or the server may
change the layer field. Layer 0 always indicates the first boot file
for a particular Boot Server type. Boot Servers capable of providing
the boot file requested in the PXE_BOOT_ITEM must respond.

Which is about as clear and useful is the rest of that document :)

I guess we're assuming that this layer business has been found to be
useless (layer is always zero) and that the "efi" suffix is the new
convention. But Jarek's patch doesn't do this and works, so this must
only be a server-side thing (ie, using Jarek's patch, the file has to be
renamed as <name>.0 on the TFTP server, the client doesn't care what it
is. Don't know what to do there, I'm tempted to make the behaviour the
same in every case, but if everybody else is booting <name>.efi files,
that may be confusing.

Third,

both patches, AFAIK only address Proxy-DHCP mode, which has separate
code from that sending PXE options with "normal" DHCP when a proxy-dhcp
server isn't used. Should the modifications to the PXE options be made
in that case too?

Fourth,>> - It gives more flexibility: the workaround can be applied only
Post by Michael Kuron
Post by Jarek Polok
to predefined <tag> and <CSA> (sorry - patched man page should be
improved to state that clearly): so we can use that to implement
- match on given hwaddr prefix with dhcp-match, then tag
- match on tag and client architecture and apply workaround only
then.
You can also use tags with my patch and achieve the same thing. For
example, if you want clients with tag abcd to display a menu with two
entries and all other clients to boot directly to the first entry (which
for them is the only entry, thus invoking my workaround), you should be
able to use something like
Post by Michael Kuron
pxe-service=BC_EFI,iPXE,pxelinux
pxe-service=tag:abcd,BC_EFI,iPXE,ipxe
Post by Jarek Polok
- setting of sname is indeed because I found 2 clients which did not
want to boot without it ..
Ok, then I suggest we add that to my patch.
Post by Jarek Polok
<name>.0 vs. <name>.efi
The <name>.0 for X86PC can’t be changed due to backwards
compatibility, otherwise everybody would have to update their config
files. I’d be ok with not automatically adding an extension for all
other architectures though. However, that would be inconsistent and also
backwards-incompatible, though I wouldn’t worry too much about the
latter as googling for "pxe-service=..." does not yield any meaningful
hits for anything but x86PC, IA32_EFI, BC_EFI and X86-64_EFI.
Post by Michael Kuron
Michael
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Setting ->siaddr

My feeling that that ->siaddr should be set to the local address
whenever the discover is received on port 68, no matter how many menu
items there are. And related, the code below

/* Provide the bootfile here, for gPXE, and in case we have no menu
and and set discovery_control = 8 */

which also sets ->siaddr, should be lower priority, it should only run
when receiving on 4011. That code can also only run when num_services ==
0, given its function.


Comments?


Cheers,

Simon.
Jarek Polok
2016-05-10 15:42:30 UTC
Permalink
Hi
Post by Simon Kelley
Lots of good info. Thanks everybody. Some more queries.
First, I'm minded to go with Michael's choice for "enabling"
workarounds; ie do what's needed to make things work with buggy PXe
menu's when there's exactly one relevant menu entry.
OK, so if num_services > 1 the current behavior is expected
(working on BIOS not working on UEFI) , right ?

Maybe an additional log message could be provided in such case ?

Also, Michael's patch works for CSA = 6,7,8 and 9 -> please add CSA = 11
too

(aarch64 EFI, I have same problems there on 3 different arm 64
systems):

or maybe that should be the default for all CSA's ?

(to avoid necessity of changing source code for any other arches in
the future ?)
Post by Simon Kelley
Second,
<name>.0 vs. <name>.efi
[...]
Post by Simon Kelley
convention. But Jarek's patch doesn't do this and works, so this must
only be a server-side thing (ie, using Jarek's patch, the file has to be
renamed as <name>.0 on the TFTP server, the client doesn't care what it
is. Don't know what to do there, I'm tempted to make the behaviour the
same in every case, but if everybody else is booting <name>.efi files,
that may be confusing.
In our experience (lots of hw models PXE booted since .. some time) the
.0 was only needed in some early PXE BIOSes and only when using PXE
menu (the proxy DHCP mode).

I personally think that current PXE/BIOS behavior is confusing (auto
adding .0): but as it was pointed out already changing that would
break backwards compatibility ... so guess .0 for x86PC and .efi for CSA
= 6,7,8,9 and 11 (perhaps other ??) will be more consistent ..

(or perhaps an option to make dnsmasq not to add suffixes there would
be a possibility too ? ...)
Post by Simon Kelley
Third,
both patches, AFAIK only address Proxy-DHCP mode, which has separate
code from that sending PXE options with "normal" DHCP when a proxy-dhcp
server isn't used. Should the modifications to the PXE options be made
in that case too?
There should not be a need for that I believe: when dnsmasq operates
in 'standard' mode it acts as a boot server already: what Michael's
patch does for proxyDHCP is to 'downgrade' the 'PXE built-in menu
system' to reply as a boot server.
Post by Simon Kelley
Fourth,>> - It gives more flexibility: the workaround can be applied only
Post by Michael Kuron
Post by Jarek Polok
to predefined <tag> and <CSA> (sorry - patched man page should be
improved to state that clearly): so we can use that to implement
- match on given hwaddr prefix with dhcp-match, then tag
- match on tag and client architecture and apply workaround only
then.
You can also use tags with my patch and achieve the same thing.
Yes, indeed, - sorry must have been looking at wrong code ...

[...]

Thanks !

Best Regards

Jarek

__
-------------------------------------------------------
_ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _
_ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _
______________________________________+41_75_411_9487 _
Simon Kelley
2016-05-10 16:44:28 UTC
Permalink
I just pushed my take on this to git. It's untested, and covers what I
think are the correct choices so far. Please could you all test?

I picked

1) <filename>.0 in workaround mode, to match all other situations.
2) Workaround in non-proxy mode too.
3) Workaround engaged for CAS 6,7,8,9 only.
4) sname filed always set.

I'd like to release 2.76 ASAP so I've chosen to make an RC1 release, but
that doesn't mean that I think this patch is right, or that I won't
accept changes before the final release.


Cheers,

Simon.
Post by Jarek Polok
Hi
Post by Simon Kelley
Lots of good info. Thanks everybody. Some more queries.
First, I'm minded to go with Michael's choice for "enabling"
workarounds; ie do what's needed to make things work with buggy PXe
menu's when there's exactly one relevant menu entry.
OK, so if num_services > 1 the current behavior is expected
(working on BIOS not working on UEFI) , right ?
Maybe an additional log message could be provided in such case ?
Also, Michael's patch works for CSA = 6,7,8 and 9 -> please add CSA = 11
too
(aarch64 EFI, I have same problems there on 3 different arm 64
or maybe that should be the default for all CSA's ?
(to avoid necessity of changing source code for any other arches in
the future ?)
Post by Simon Kelley
Second,
Don't crash with divide-by-zero if an IPv6 dhcp-range
is declared as a whole /64.
(ie xx::0 to xx::ffff:ffff:ffff:ffff)
Thanks to Laurent Bendel for spotting this problem.

Add support for a TTL parameter in --host-record and
--cname.

Add --dhcp-ttl option.

Add --tftp-mtu option. Thanks to Patrick McLean for the
initial patch.

Check return-code of inet_pton() when parsing dhcp-option.
Bad addresses could fail to generate errors and result in
garbage dhcp-options being sent. Thanks to Marc Branchaud
for spotting this.

Fix wrong value for EDNS UDP packet size when using
--servers-file to define upstream DNS servers. Thanks to
Scott Bonar for the bug report.

Move the dhcp_release and dhcp_lease_time tools from
contrib/wrt to contrib/lease-tools.

Add dhcp_release6 to contrib/lease-tools. Many thanks
to Sergey Nechaev for this code.

To avoid filling logs in configurations which define
many upstream nameservers, don't log more that 30 servers.
The number to be logged can be changed as SERVERS_LOGGED
in src/config.h.
Post by Jarek Polok
Post by Simon Kelley
<name>.0 vs. <name>.efi
[...]
Post by Simon Kelley
convention. But Jarek's patch doesn't do this and works, so this must
only be a server-side thing (ie, using Jarek's patch, the file has to be
renamed as <name>.0 on the TFTP server, the client doesn't care what it
is. Don't know what to do there, I'm tempted to make the behaviour the
same in every case, but if everybody else is booting <name>.efi files,
that may be confusing.
In our experience (lots of hw models PXE booted since .. some time) the
.0 was only needed in some early PXE BIOSes and only when using PXE
menu (the proxy DHCP mode).
I personally think that current PXE/BIOS behavior is confusing (auto
adding .0): but as it was pointed out already changing that would
break backwards compatibility ... so guess .0 for x86PC and .efi for CSA
= 6,7,8,9 and 11 (perhaps other ??) will be more consistent ..
(or perhaps an option to make dnsmasq not to add suffixes there would
be a possibility too ? ...)
Post by Simon Kelley
Third,
both patches, AFAIK only address Proxy-DHCP mode, which has separate
code from that sending PXE options with "normal" DHCP when a proxy-dhcp
server isn't used. Should the modifications to the PXE options be made
in that case too?
There should not be a need for that I believe: when dnsmasq operates
in 'standard' mode it acts as a boot server already: what Michael's
patch does for proxyDHCP is to 'downgrade' the 'PXE built-in menu
system' to reply as a boot server.
Post by Simon Kelley
Fourth,>> - It gives more flexibility: the workaround can be applied only
Post by Michael Kuron
Post by Jarek Polok
to predefined <tag> and <CSA> (sorry - patched man page should be
improved to state that clearly): so we can use that to implement
- match on given hwaddr prefix with dhcp-match, then tag
- match on tag and client architecture and apply workaround only
then.
You can also use tags with my patch and achieve the same thing.
Yes, indeed, - sorry must have been looking at wrong code ...
[...]
Thanks !
Best Regards
Jarek
__
-------------------------------------------------------
_ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _
_ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _
______________________________________+41_75_411_9487 _
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Jarek Polok
2016-05-11 06:04:30 UTC
Permalink
Post by Simon Kelley
I just pushed my take on this to git. It's untested, and covers what I
think are the correct choices so far. Please could you all test?
I picked
1) <filename>.0 in workaround mode, to match all other situations.
If I understand well then:

pxe-service=..., /path/pxelinux -> sends /path/pxelinux.0
pxe-service=..., /path/bootx64.efi -> sends /path/bootx64.efi.0

?
Post by Simon Kelley
2) Workaround in non-proxy mode too.
3) Workaround engaged for CAS 6,7,8,9 only.
Could you please add CSA 10 and 11 there as well ?

10 - ARM 32-bit UEFI -> most likely will need it too ..
11 - ARM 64-bit UEFI -> needs it (we have confirmed this
on 3 different models)


The full up to date list of arches seems to be there:


http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#processor-architecture

(but only types 0 to 9 are defined in an rfc (rfc4578) ..)
Post by Simon Kelley
4) sname filed always set.
I'd like to release 2.76 ASAP so I've chosen to make an RC1 release, but
that doesn't mean that I think this patch is right, or that I won't
accept changes before the final release.
Thanks

Jarek
Post by Simon Kelley
Cheers,
Simon.
Post by Jarek Polok
Hi
Post by Simon Kelley
Lots of good info. Thanks everybody. Some more queries.
First, I'm minded to go with Michael's choice for "enabling"
workarounds; ie do what's needed to make things work with buggy PXe
menu's when there's exactly one relevant menu entry.
OK, so if num_services > 1 the current behavior is expected
(working on BIOS not working on UEFI) , right ?
Maybe an additional log message could be provided in such case ?
Also, Michael's patch works for CSA = 6,7,8 and 9 -> please add CSA = 11
too
(aarch64 EFI, I have same problems there on 3 different arm 64
or maybe that should be the default for all CSA's ?
(to avoid necessity of changing source code for any other arches in
the future ?)
Post by Simon Kelley
Second,
Don't crash with divide-by-zero if an IPv6 dhcp-range
is declared as a whole /64.
(ie xx::0 to xx::ffff:ffff:ffff:ffff)
Thanks to Laurent Bendel for spotting this problem.
Add support for a TTL parameter in --host-record and
--cname.
Add --dhcp-ttl option.
Add --tftp-mtu option. Thanks to Patrick McLean for the
initial patch.
Check return-code of inet_pton() when parsing dhcp-option.
Bad addresses could fail to generate errors and result in
garbage dhcp-options being sent. Thanks to Marc Branchaud
for spotting this.
Fix wrong value for EDNS UDP packet size when using
--servers-file to define upstream DNS servers. Thanks to
Scott Bonar for the bug report.
Move the dhcp_release and dhcp_lease_time tools from
contrib/wrt to contrib/lease-tools.
Add dhcp_release6 to contrib/lease-tools. Many thanks
to Sergey Nechaev for this code.
To avoid filling logs in configurations which define
many upstream nameservers, don't log more that 30 servers.
The number to be logged can be changed as SERVERS_LOGGED
in src/config.h.
Post by Jarek Polok
Post by Simon Kelley
<name>.0 vs. <name>.efi
[...]
Post by Simon Kelley
convention. But Jarek's patch doesn't do this and works, so this must
only be a server-side thing (ie, using Jarek's patch, the file has to be
renamed as <name>.0 on the TFTP server, the client doesn't care what it
is. Don't know what to do there, I'm tempted to make the behaviour the
same in every case, but if everybody else is booting <name>.efi files,
that may be confusing.
In our experience (lots of hw models PXE booted since .. some time) the
.0 was only needed in some early PXE BIOSes and only when using PXE
menu (the proxy DHCP mode).
I personally think that current PXE/BIOS behavior is confusing (auto
adding .0): but as it was pointed out already changing that would
break backwards compatibility ... so guess .0 for x86PC and .efi for CSA
= 6,7,8,9 and 11 (perhaps other ??) will be more consistent ..
(or perhaps an option to make dnsmasq not to add suffixes there would
be a possibility too ? ...)
Post by Simon Kelley
Third,
both patches, AFAIK only address Proxy-DHCP mode, which has separate
code from that sending PXE options with "normal" DHCP when a proxy-dhcp
server isn't used. Should the modifications to the PXE options be made
in that case too?
There should not be a need for that I believe: when dnsmasq operates
in 'standard' mode it acts as a boot server already: what Michael's
patch does for proxyDHCP is to 'downgrade' the 'PXE built-in menu
system' to reply as a boot server.
Post by Simon Kelley
Fourth,>> - It gives more flexibility: the workaround can be applied only
Post by Michael Kuron
Post by Jarek Polok
to predefined <tag> and <CSA> (sorry - patched man page should be
improved to state that clearly): so we can use that to implement
- match on given hwaddr prefix with dhcp-match, then tag
- match on tag and client architecture and apply workaround only
then.
You can also use tags with my patch and achieve the same thing.
Yes, indeed, - sorry must have been looking at wrong code ...
[...]
Thanks !
Best Regards
Jarek
__
-------------------------------------------------------
_ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _
_ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _
______________________________________+41_75_411_9487 _
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
--
__
-------------------------------------------------------
_ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _
_ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _
______________________________________+41_75_411_9487 _
Simon Kelley
2016-05-11 21:01:19 UTC
Permalink
Post by Jarek Polok
Post by Simon Kelley
I just pushed my take on this to git. It's untested, and covers what I
think are the correct choices so far. Please could you all test?
I picked
1) <filename>.0 in workaround mode, to match all other situations.
pxe-service=..., /path/pxelinux -> sends /path/pxelinux.0
pxe-service=..., /path/bootx64.efi -> sends /path/bootx64.efi.0
?
Yes. When the full menu code is used, and the PXE client makes a
boot-server request with a layer-number, then the filename becomes
<filename>.<layer-no>

When we're short-circuiting this by not sending a menu and just sending
a filename, to get the same behaviour we use the <filename>.0 name.
That's making the assumption that the client will always choose layer
zero, which seems to be true in practice.

To make is consistent, if we want to use just <filename>, we'd need to
stop adding the layer number in the boot-server code paths too, at least
for EFI CSAs. That's a change of behaviour that could break existing stuff.
Post by Jarek Polok
Post by Simon Kelley
2) Workaround in non-proxy mode too.
3) Workaround engaged for CAS 6,7,8,9 only.
Could you please add CSA 10 and 11 there as well ?
10 - ARM 32-bit UEFI -> most likely will need it too ..
11 - ARM 64-bit UEFI -> needs it (we have confirmed this
on 3 different models)
Seems that the best condition to use is CSA >= 6

I should add those to the option parsing too.


Cheers,

Simon.
Post by Jarek Polok
http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#processor-architecture
(but only types 0 to 9 are defined in an rfc (rfc4578) ..)
Post by Simon Kelley
4) sname filed always set.
I'd like to release 2.76 ASAP so I've chosen to make an RC1 release, but
that doesn't mean that I think this patch is right, or that I won't
accept changes before the final release.
Thanks
Jarek
Post by Simon Kelley
Cheers,
Simon.
Post by Jarek Polok
Hi
Post by Simon Kelley
Lots of good info. Thanks everybody. Some more queries.
First, I'm minded to go with Michael's choice for "enabling"
workarounds; ie do what's needed to make things work with buggy PXe
menu's when there's exactly one relevant menu entry.
OK, so if num_services > 1 the current behavior is expected
(working on BIOS not working on UEFI) , right ?
Maybe an additional log message could be provided in such case ?
Also, Michael's patch works for CSA = 6,7,8 and 9 -> please add CSA = 11
too
(aarch64 EFI, I have same problems there on 3 different arm 64
or maybe that should be the default for all CSA's ?
(to avoid necessity of changing source code for any other arches in
the future ?)
Post by Simon Kelley
Second,
Don't crash with divide-by-zero if an IPv6 dhcp-range
is declared as a whole /64.
(ie xx::0 to xx::ffff:ffff:ffff:ffff)
Thanks to Laurent Bendel for spotting this problem.
Add support for a TTL parameter in --host-record and
--cname.
Add --dhcp-ttl option.
Add --tftp-mtu option. Thanks to Patrick McLean for the
initial patch.
Check return-code of inet_pton() when parsing dhcp-option.
Bad addresses could fail to generate errors and result in
garbage dhcp-options being sent. Thanks to Marc Branchaud
for spotting this.
Fix wrong value for EDNS UDP packet size when using
--servers-file to define upstream DNS servers. Thanks to
Scott Bonar for the bug report.
Move the dhcp_release and dhcp_lease_time tools from
contrib/wrt to contrib/lease-tools.
Add dhcp_release6 to contrib/lease-tools. Many thanks
to Sergey Nechaev for this code.
To avoid filling logs in configurations which define
many upstream nameservers, don't log more that 30 servers.
The number to be logged can be changed as SERVERS_LOGGED
in src/config.h.
Post by Jarek Polok
Post by Simon Kelley
<name>.0 vs. <name>.efi
[...]
Post by Simon Kelley
convention. But Jarek's patch doesn't do this and works, so this must
only be a server-side thing (ie, using Jarek's patch, the file has to be
renamed as <name>.0 on the TFTP server, the client doesn't care what it
is. Don't know what to do there, I'm tempted to make the behaviour the
same in every case, but if everybody else is booting <name>.efi files,
that may be confusing.
In our experience (lots of hw models PXE booted since .. some time) the
.0 was only needed in some early PXE BIOSes and only when using PXE
menu (the proxy DHCP mode).
I personally think that current PXE/BIOS behavior is confusing (auto
adding .0): but as it was pointed out already changing that would
break backwards compatibility ... so guess .0 for x86PC and .efi for CSA
= 6,7,8,9 and 11 (perhaps other ??) will be more consistent ..
(or perhaps an option to make dnsmasq not to add suffixes there would
be a possibility too ? ...)
Post by Simon Kelley
Third,
both patches, AFAIK only address Proxy-DHCP mode, which has separate
code from that sending PXE options with "normal" DHCP when a proxy-dhcp
server isn't used. Should the modifications to the PXE options be made
in that case too?
There should not be a need for that I believe: when dnsmasq operates
in 'standard' mode it acts as a boot server already: what Michael's
patch does for proxyDHCP is to 'downgrade' the 'PXE built-in menu
system' to reply as a boot server.
Post by Simon Kelley
Fourth,>> - It gives more flexibility: the workaround can be applied only
Post by Michael Kuron
Post by Jarek Polok
to predefined <tag> and <CSA> (sorry - patched man page should be
improved to state that clearly): so we can use that to implement
- match on given hwaddr prefix with dhcp-match, then tag
- match on tag and client architecture and apply workaround only
then.
You can also use tags with my patch and achieve the same thing.
Yes, indeed, - sorry must have been looking at wrong code ...
[...]
Thanks !
Best Regards
Jarek
__
-------------------------------------------------------
_ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _
_ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _
______________________________________+41_75_411_9487 _
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Simon Kelley
2016-05-11 21:22:27 UTC
Permalink
Post by Jarek Polok
http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#processor-architecture
(but only types 0 to 9 are defined in an rfc (rfc4578) ..)
.. and RFC 4578 has an error and swaps BC_EFI and x86-64_EFI. Dnsmasq
followed 4578 and has the same error. I've just pushed the fix for that,
but it means that if people were using BC_EFI as the CSA, because that
made it work, they'll need to change their configs to use x86-64_EFI
instead.


Cheers,

Simon.
Michael Kuron
2016-05-14 17:47:06 UTC
Permalink
I have included a patch below that makes essentially two modifications to get PXE working with the UEFI firmware in VMware.
- It only appends the layer number to the file name on BIOS x86.
- It always redirects the client to port 4011. To do that, only the siaddr is set and neither a boot file nor a PXE menu are included in the Offer sent upon receiving the Discover. In reaction to the ACK it then sends an ACK which includes either the single boot file name and server, or the PXE menu.

This patch works to the same degree as my patch did. VMware boots fine with a single boot service, and the menu also works if you specify multiple, however you have to blindly navigate the menu because it is not shown on screen.

Michael


--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@ -63,7 +63,7 @@ static void pxe_misc(struct dhcp_packet *mess, unsigned char *end, unsigned char
static int prune_vendor_opts(struct dhcp_netid *netid);
static struct dhcp_opt *pxe_opts(int pxe_arch, struct dhcp_netid *netid, struct in_addr local, time_t now);
struct dhcp_boot *find_boot(struct dhcp_netid *netid);
-static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dhcp_packet *mess, struct in_addr local, time_t now);
+static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dhcp_packet *mess, struct in_addr local, time_t now, int pxe);

size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
size_t sz, time_t now, int unicast_dest, int *is_inform, int pxe, struct in_addr fallback)
@@ -824,7 +824,10 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
else
mess->siaddr = context->local;

- snprintf((char *)mess->file, sizeof(mess->file), "%s.%d", service->basename, layer);
+ if (pxearch == 0)
+ snprintf((char *)mess->file, sizeof(mess->file), "%s.%d", service->basename, layer);
+ else
+ strncpy((char *)mess->file, service->basename, sizeof(mess->file));
option_put(mess, end, OPTION_MESSAGE_TYPE, 1, DHCPACK);
option_put(mess, end, OPTION_SERVER_IDENTIFIER, INADDRSZ, htonl(context->local.s_addr));
pxe_misc(mess, end, uuid);
@@ -879,11 +882,10 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,

clear_packet(mess, end);

- /* Only do workaround for replies to 4011 */
- if (!pxe)
- mess->siaddr = tmp->local;
- else
- workaround = pxe_uefi_workaround(pxearch, tagif_netid, mess, tmp->local, now);
+ /* Redirect the client to port 4011 */
+ mess->siaddr = tmp->local;
+ /* Returns true if only one matching service is available. On port 4011, it also inserts the boot file and server name. */
+ workaround = pxe_uefi_workaround(pxearch, tagif_netid, mess, tmp->local, now, pxe);

if (!workaround && boot)
{
@@ -903,7 +905,7 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
option_put(mess, end, OPTION_SERVER_IDENTIFIER, INADDRSZ, htonl(tmp->local.s_addr));
pxe_misc(mess, end, uuid);
prune_vendor_opts(tagif_netid);
- if (!workaround)
+ if (pxe && !workaround)
do_encap_opts(pxe_opts(pxearch, tagif_netid, tmp->local, now), OPTION_VENDOR_CLASS_OPT, DHOPT_VENDOR_MATCH, mess, end, 0);

log_packet("PXE", NULL, emac, emac_len, iface_name, ignore ? "proxy-ignored" : "proxy", NULL, mess->xid);
@@ -1989,7 +1991,7 @@ static int prune_vendor_opts(struct dhcp_netid *netid)
and jamb the data direct into the DHCP file, siaddr and sname fields.
Note that in this case, we have to assume that layer zero would be requested
by the client PXE stack. */
-static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dhcp_packet *mess, struct in_addr local, time_t now)
+static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dhcp_packet *mess, struct in_addr local, time_t now, int pxe)
{
struct pxe_service *service, *found;

@@ -2009,6 +2011,9 @@ static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dh
if (!found)
return 0; /* No relevant menu items. */

+ if (!pxe)
+ return 1;
+
if (found->sname)
{
mess->siaddr = a_record_from_hosts(found->sname, now);
@@ -2024,7 +2029,10 @@ static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dh
inet_ntop(AF_INET, &mess->siaddr, (char *)mess->sname, INET_ADDRSTRLEN);
}

- snprintf((char *)mess->file, sizeof(mess->file), "%s.0", found->basename);
+ if (pxe_arch == 0)
+ snprintf((char *)mess->file, sizeof(mess->file), "%s.0", service->basename);
+ else
+ strncpy((char *)mess->file, found->basename, sizeof(mess->file));

return 1;
}
@@ -2563,7 +2571,7 @@ static void do_options(struct dhcp_context *context,
if (context && pxe_arch != -1)
{
pxe_misc(mess, end, uuid);
- if (!pxe_uefi_workaround(pxe_arch, tagif, mess, context->local, now))
+ if (!pxe_uefi_workaround(pxe_arch, tagif, mess, context->local, now, 0))
config_opts = pxe_opts(pxe_arch, tagif, context->local, now);
}
Simon Kelley
2016-05-14 19:55:18 UTC
Permalink
Great, thanks. I've applied your patch and made a further change:
instead of changing the filename behaviour based on CSA, it looks at the
filename provided. If it has a suffix (strictly, if it includes a '.'
character) then the filename is used as-is. Otherwise it as the layer
added as suffix.

That seems most sensible. It has a small risk of breaking existing
setups with files called boot.bios.0. but that can be handled with a
release-note in the changelog.


In git now.

Simon.
Post by Michael Kuron
I have included a patch below that makes essentially two modifications to get PXE working with the UEFI firmware in VMware.
- It only appends the layer number to the file name on BIOS x86.
- It always redirects the client to port 4011. To do that, only the siaddr is set and neither a boot file nor a PXE menu are included in the Offer sent upon receiving the Discover. In reaction to the ACK it then sends an ACK which includes either the single boot file name and server, or the PXE menu.
This patch works to the same degree as my patch did. VMware boots fine with a single boot service, and the menu also works if you specify multiple, however you have to blindly navigate the menu because it is not shown on screen.
Michael
--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@ -63,7 +63,7 @@ static void pxe_misc(struct dhcp_packet *mess, unsigned char *end, unsigned char
static int prune_vendor_opts(struct dhcp_netid *netid);
static struct dhcp_opt *pxe_opts(int pxe_arch, struct dhcp_netid *netid, struct in_addr local, time_t now);
struct dhcp_boot *find_boot(struct dhcp_netid *netid);
-static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dhcp_packet *mess, struct in_addr local, time_t now);
+static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dhcp_packet *mess, struct in_addr local, time_t now, int pxe);
size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
size_t sz, time_t now, int unicast_dest, int *is_inform, int pxe, struct in_addr fallback)
@@ -824,7 +824,10 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
else
mess->siaddr = context->local;
- snprintf((char *)mess->file, sizeof(mess->file), "%s.%d", service->basename, layer);
+ if (pxearch == 0)
+ snprintf((char *)mess->file, sizeof(mess->file), "%s.%d", service->basename, layer);
+ else
+ strncpy((char *)mess->file, service->basename, sizeof(mess->file));
option_put(mess, end, OPTION_MESSAGE_TYPE, 1, DHCPACK);
option_put(mess, end, OPTION_SERVER_IDENTIFIER, INADDRSZ, htonl(context->local.s_addr));
pxe_misc(mess, end, uuid);
@@ -879,11 +882,10 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
clear_packet(mess, end);
- /* Only do workaround for replies to 4011 */
- if (!pxe)
- mess->siaddr = tmp->local;
- else
- workaround = pxe_uefi_workaround(pxearch, tagif_netid, mess, tmp->local, now);
+ /* Redirect the client to port 4011 */
+ mess->siaddr = tmp->local;
+ /* Returns true if only one matching service is available. On port 4011, it also inserts the boot file and server name. */
+ workaround = pxe_uefi_workaround(pxearch, tagif_netid, mess, tmp->local, now, pxe);
if (!workaround && boot)
{
@@ -903,7 +905,7 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
option_put(mess, end, OPTION_SERVER_IDENTIFIER, INADDRSZ, htonl(tmp->local.s_addr));
pxe_misc(mess, end, uuid);
prune_vendor_opts(tagif_netid);
- if (!workaround)
+ if (pxe && !workaround)
do_encap_opts(pxe_opts(pxearch, tagif_netid, tmp->local, now), OPTION_VENDOR_CLASS_OPT, DHOPT_VENDOR_MATCH, mess, end, 0);
log_packet("PXE", NULL, emac, emac_len, iface_name, ignore ? "proxy-ignored" : "proxy", NULL, mess->xid);
@@ -1989,7 +1991,7 @@ static int prune_vendor_opts(struct dhcp_netid *netid)
and jamb the data direct into the DHCP file, siaddr and sname fields.
Note that in this case, we have to assume that layer zero would be requested
by the client PXE stack. */
-static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dhcp_packet *mess, struct in_addr local, time_t now)
+static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dhcp_packet *mess, struct in_addr local, time_t now, int pxe)
{
struct pxe_service *service, *found;
@@ -2009,6 +2011,9 @@ static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dh
if (!found)
return 0; /* No relevant menu items. */
+ if (!pxe)
+ return 1;
+
if (found->sname)
{
mess->siaddr = a_record_from_hosts(found->sname, now);
@@ -2024,7 +2029,10 @@ static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dh
inet_ntop(AF_INET, &mess->siaddr, (char *)mess->sname, INET_ADDRSTRLEN);
}
- snprintf((char *)mess->file, sizeof(mess->file), "%s.0", found->basename);
+ if (pxe_arch == 0)
+ snprintf((char *)mess-snprintf((char *)mess->file, sizeof(mess->file),
strchr(service->basename, '.') ? "%s" :"%s.%d",
service->basename, layer);>file, sizeof(mess->file), "%s.0",
service->basename);
Post by Michael Kuron
+ else
+ strncpy((char *)mess->file, found->basename, sizeof(mess->file));
return 1;
}
@@ -2563,7 +2571,7 @@ static void do_options(struct dhcp_context *context,
if (context && pxe_arch != -1)
{
pxe_misc(mess, end, uuid);
- if (!pxe_uefi_workaround(pxe_arch, tagif, mess, context->local, now))
+ if (!pxe_uefi_workaround(pxe_arch, tagif, mess, context->local, now, 0))
config_opts = pxe_opts(pxe_arch, tagif, context->local, now);
}
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Michael Kuron
2016-05-15 08:03:06 UTC
Permalink
Hi Simon,

thanks, it’s working fine for me now. Before releasing 2.76, it would be good if more people could test this on actual hardware.
Also, there’s one more item that needs to go into the release notes: we now redirect all clients to port 4011, including the BIOS clients. This is a change in behavior over the previous release, where the option 43 menu was sent on port 68. This could potentially break things for some very old and broken PXE implementations. It’s unlikely, since the port 4011 stuff has always been part of the PXE spec, but possible. I don’t think it’s really necessary, but I have included a patch below that restricts the port 4011 redirect to CSA >= 6. With that patch, the PXE behavior for BIOS clients is exactly what it was in older releases.

Michael


--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@ -882,8 +882,13 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,

clear_packet(mess, end);

- /* Redirect the client to port 4011 */
- mess->siaddr = tmp->local;
+ /* Redirect EFI clients to port 4011 */
+ int redirect4011 = 0;
+ if (pxearch >= 6)
+ {
+ redirect4011 = 1;
+ mess->siaddr = tmp->local;
+ }
/* Returns true if only one matching service is available. On port 4011,
it also inserts the boot file and server name. */
workaround = pxe_uefi_workaround(pxearch, tagif_netid, mess, tmp->local, now, pxe);
@@ -906,7 +911,7 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
option_put(mess, end, OPTION_SERVER_IDENTIFIER, INADDRSZ, htonl(tmp->local.s_addr));
pxe_misc(mess, end, uuid);
prune_vendor_opts(tagif_netid);
- if (pxe && !workaround)
+ if ((pxe && !workaround) || !redirect4011)
do_encap_opts(pxe_opts(pxearch, tagif_netid, tmp->local, now), OPTION_VENDOR_CLASS_OPT, DHOPT_VENDOR_MATCH, mess, end, 0);

log_packet("PXE", NULL, emac, emac_len, iface_name, ignore ? "proxy-ignored" : "proxy", NULL, mess->xid);
Dreamcat4
2016-05-15 13:39:41 UTC
Permalink
Hi,
Tried the 2.76rc2 this morning. Seems fine / OK for me.

Have uploaded the binary here again (same place as before):

https://dl.bintray.com/dreamcat4/linux/dnsmasq/



On Sun, May 15, 2016 at 9:03 AM, Michael Kuron <
Post by Michael Kuron
Hi Simon,
thanks, it’s working fine for me now. Before releasing 2.76, it would be
good if more people could test this on actual hardware.
Also, there’s one more item that needs to go into the release notes: we
now redirect all clients to port 4011, including the BIOS clients. This is
a change in behavior over the previous release, where the option 43 menu
was sent on port 68. This could potentially break things for some very old
and broken PXE implementations. It’s unlikely, since the port 4011 stuff
has always been part of the PXE spec, but possible. I don’t think it’s
really necessary, but I have included a patch below that restricts the port
4011 redirect to CSA >= 6. With that patch, the PXE behavior for BIOS
clients is exactly what it was in older releases.
Michael
--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@ -882,8 +882,13 @@ size_t dhcp_reply(struct dhcp_context *context, char
*iface_name, int int_index,
clear_packet(mess, end);
- /* Redirect the client to port 4011 */
- mess->siaddr = tmp->local;
+ /* Redirect EFI clients to port 4011 */
+ int redirect4011 = 0;
+ if (pxearch >= 6)
+ {
+ redirect4011 = 1;
+ mess->siaddr = tmp->local;
+ }
/* Returns true if only one matching service is available. On port 4011,
it also inserts the boot file and server name. */
workaround = pxe_uefi_workaround(pxearch, tagif_netid,
mess, tmp->local, now, pxe);
@@ -906,7 +911,7 @@ size_t dhcp_reply(struct dhcp_context *context, char
*iface_name, int int_index,
option_put(mess, end, OPTION_SERVER_IDENTIFIER,
INADDRSZ, htonl(tmp->local.s_addr));
pxe_misc(mess, end, uuid);
prune_vendor_opts(tagif_netid);
- if (pxe && !workaround)
+ if ((pxe && !workaround) || !redirect4011)
do_encap_opts(pxe_opts(pxearch, tagif_netid,
tmp->local, now), OPTION_VENDOR_CLASS_OPT, DHOPT_VENDOR_MATCH, mess, end,
0);
log_packet("PXE", NULL, emac, emac_len, iface_name,
ignore ? "proxy-ignored" : "proxy", NULL, mess->xid);
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Simon Kelley
2016-05-15 19:16:53 UTC
Permalink
Post by Dreamcat4
Hi,
Tried the 2.76rc2 this morning. Seems fine / OK for me.
Great. Thanks for that.



Cheers,

Simon.
Post by Dreamcat4
https://dl.bintray.com/dreamcat4/linux/dnsmasq/
On Sun, May 15, 2016 at 9:03 AM, Michael Kuron <
Post by Michael Kuron
Hi Simon,
thanks, it’s working fine for me now. Before releasing 2.76, it would be
good if more people could test this on actual hardware.
Also, there’s one more item that needs to go into the release notes: we
now redirect all clients to port 4011, including the BIOS clients. This is
a change in behavior over the previous release, where the option 43 menu
was sent on port 68. This could potentially break things for some very old
and broken PXE implementations. It’s unlikely, since the port 4011 stuff
has always been part of the PXE spec, but possible. I don’t think it’s
really necessary, but I have included a patch below that restricts the port
4011 redirect to CSA >= 6. With that patch, the PXE behavior for BIOS
clients is exactly what it was in older releases.
Michael
--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@ -882,8 +882,13 @@ size_t dhcp_reply(struct dhcp_context *context, char
*iface_name, int int_index,
clear_packet(mess, end);
- /* Redirect the client to port 4011 */
- mess->siaddr = tmp->local;
+ /* Redirect EFI clients to port 4011 */
+ int redirect4011 = 0;
+ if (pxearch >= 6)
+ {
+ redirect4011 = 1;
+ mess->siaddr = tmp->local;
+ }
/* Returns true if only one matching service is
available. On port 4011,
it also inserts the boot file and server name. */
workaround = pxe_uefi_workaround(pxearch, tagif_netid,
mess, tmp->local, now, pxe);
@@ -906,7 +911,7 @@ size_t dhcp_reply(struct dhcp_context *context, char
*iface_name, int int_index,
option_put(mess, end, OPTION_SERVER_IDENTIFIER,
INADDRSZ, htonl(tmp->local.s_addr));
pxe_misc(mess, end, uuid);
prune_vendor_opts(tagif_netid);
- if (pxe && !workaround)
+ if ((pxe && !workaround) || !redirect4011)
do_encap_opts(pxe_opts(pxearch, tagif_netid,
tmp->local, now), OPTION_VENDOR_CLASS_OPT, DHOPT_VENDOR_MATCH, mess, end,
0);
log_packet("PXE", NULL, emac, emac_len, iface_name,
ignore ? "proxy-ignored" : "proxy", NULL, mess->xid);
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Simon Kelley
2016-05-15 19:16:31 UTC
Permalink
Post by Michael Kuron
Hi Simon,
thanks, it’s working fine for me now. Before releasing 2.76, it would
be good if more people could test this on actual hardware. Also,
there’s one more item that needs to go into the release notes: we now
redirect all clients to port 4011, including the BIOS clients. This
is a change in behavior over the previous release, where the option
43 menu was sent on port 68. This could potentially break things for
some very old and broken PXE implementations. It’s unlikely, since
the port 4011 stuff has always been part of the PXE spec, but
possible. I don’t think it’s really necessary, but I have included a
patch below that restricts the port 4011 redirect to CSA >= 6. With
that patch, the PXE behavior for BIOS clients is exactly what it was
in older releases.
Michael
Patch applied. That makes me happy. I've also added a description of the
changes to CHANGELOG. Does that make sense, or have I horribly mangled this?

Cheers

Simon.

Loading...