Syslinux - Mar 2016 - Updated status on UEFI compliant version of the pxechn-module

Hi,

Ok, when can we then anticipate pxe-chaining to be possible with syslinux under
the UEFI architecture? Are there any plans to implement both correct interfacing
to UEFI as well as the issue of arbitrary UEFI images? Haven't tried to read
the UEFI-specification as it is sub 3000-pages long, so I am a bit in the dark
as to the changes in architecture from BIOS to UEFI. It has been "fun"
enough to read the PXE 2.1-specification and see how it manifests its horror in
actual PXE ROM implementations and its impact on the PXE boot-process on various
hardware (Microsoft and others blame unworking features of the DHCP options, but
in actuality the fault seems to lie the rather vague specification of PXE 2.1 as
far as I can see).

I just compiled up the 6.04-prerelease and can see that the pxechn-module has
been removed from the two efi-trees. As a sidenote: the NEWS-file in the
6.04-prerelease is missing information about changes introduced in it (seems to
be the file from 6.03).

As another sidenote and possible separate thread: since I couldn't get UEFI
to boot pxelinux 6.03 properly before I saw your dhcp options fix (vendor
encapsulated options), I implemented a simple PXE boot server ack-packet UDP
server in perl (the PXE client basically tries to perform a PXE boot server
discovery procedure). Works like a charm without the dhcp options under all the
Intel Boot Agent versions I tried - only need to set the mtftp-server address as
per recommendations in the PXE 2.1 spec. Is there any interest in me publishing
this boot server ack-packet script for others to use? Microsoft and others want
us to drop DHCP options and instead implement iphelpers in the router (if
clients and servers are on separate subnets), but shouldn't be necessary as
far as I can see. The origin of all this mess is again the PXE specification in
my opinion...

   Jan-Frode

________________________________________
From: Gene Cumm <gene.cumm at gmail.com>
Sent: Tuesday, March 15, 2016 13:42
To: Jan Frode J?ger
Cc: syslinux at zytor.com
Subject: Re: [syslinux] Updated status on UEFI compliant version of the
pxechn-module

On Tue, Mar 15, 2016 at 3:51 AM, Jan Frode J?ger <syslinux at zytor.com>
wrote:
> Hi,
>
>
> I have browsed through your syslinux archives and see that the issue of an
UEFI compliant version of the pxechn-module has come up several times:
>
>
> http://www.syslinux.org/archives/2014-August/022611.html
>
> http://www.syslinux.org/archives/2015-March/023320.html
>
> http://www.syslinux.org/archives/2015-September/024231.html
>
>
> Now the issue as I understand it is that the original pxechn-module has
been written to interface with legacy BIOS and not UEFI. It also seems that
Patricks update as of March 2015 gave positive indications that a general fix
for com32-modules were possible.
>
>
> It would have been nice to receive some update on both com32-module
compliance for the UEFI architecture as well as for the pxechn-module in
specific. We have a setup at my workplace that are dependant upon this working
and right now the only solution is to use legacy BIOS PXE-boot.
>
>
> Is there any fix for this in the recently mentioned 6.04 pre-release (soon
to become release?)?
No, I removed all modules with BIOSisms from UEFI builds like pxechn.c32.

More importantly, Syslinux can't load arbitrary UEFI images yet.

--
-Gene

On Tue, Mar 15, 2016 at 9:32 AM, Jan Frode J?ger
<jan.frode.jaeger at ntnu.no> wrote:
> Hi,
>
> Ok, when can we then anticipate pxe-chaining to be possible with syslinux
under the UEFI architecture? Are there any plans to implement both correct
interfacing to UEFI as well as the issue of arbitrary UEFI images? Haven't
tried to read the UEFI-specification as it is sub 3000-pages long, so I am a bit
in the dark as to the changes in architecture from BIOS to UEFI. It has been
"fun" enough to read the PXE 2.1-specification and see how it
manifests its horror in actual PXE ROM implementations and its impact on the PXE
boot-process on various hardware (Microsoft and others blame unworking features
of the DHCP options, but in actuality the fault seems to lie the rather vague
specification of PXE 2.1 as far as I can see).
Without trying to figure out where data is stored or the possibility
of calls to manipulate the data, I can't speak for the possibility of
implementing anything that manipulates the options like pxechn.c32 for
UEFI.  I'd like to get UEFI chaining working first.

The shear length comparison speaks a lot for the differences.  Yes,
I've read through most of the PXE spec as it relates to the boot
process.  As bad as you think PXE is, consider how UEFI has been a
moving target in some respects.

What do you expect to PXE chainload?  If you could provide details on
what you hope to achieve, someone might be able to offer a suggestion
or workaround.
> I just compiled up the 6.04-prerelease and can see that the pxechn-module
has been removed from the two efi-trees. As a sidenote: the NEWS-file in the
6.04-prerelease is missing information about changes introduced in it (seems to
be the file from 6.03).
NEWS has NOT been updated yet.
> As another sidenote and possible separate thread: since I couldn't get
UEFI to boot pxelinux 6.03 properly before I saw your dhcp options fix (vendor
encapsulated options), I implemented a simple PXE boot server ack-packet UDP
server in perl (the PXE client basically tries to perform a PXE boot server
discovery procedure). Works like a charm without the dhcp options under all the
Intel Boot Agent versions I tried - only need to set the mtftp-server address as
per recommendations in the PXE 2.1 spec. Is there any interest in me publishing
this boot server ack-packet script for others to use? Microsoft and others want
us to drop DHCP options and instead implement iphelpers in the router (if
clients and servers are on separate subnets), but shouldn't be necessary as
far as I can see. The origin of all this mess is again the PXE specification in
my opinion...
Intel Boot Agent?  Really?  I've NEVER seen mention of "Intel Boot
Agent" on UEFI.

I'd certainly be interested in this Perl script.

-- 
-Gene
> ________________________________________
> From: Gene Cumm <gene.cumm at gmail.com>
> Sent: Tuesday, March 15, 2016 13:42
> To: Jan Frode J?ger
> Cc: syslinux at zytor.com
> Subject: Re: [syslinux] Updated status on UEFI compliant version of the
pxechn-module
>
> On Tue, Mar 15, 2016 at 3:51 AM, Jan Frode J?ger <syslinux at
zytor.com> wrote:
>> Hi,
>>
>>
>> I have browsed through your syslinux archives and see that the issue of
an UEFI compliant version of the pxechn-module has come up several times:
>>
>>
>> http://www.syslinux.org/archives/2014-August/022611.html
>>
>> http://www.syslinux.org/archives/2015-March/023320.html
>>
>> http://www.syslinux.org/archives/2015-September/024231.html
>>
>>
>> Now the issue as I understand it is that the original pxechn-module has
been written to interface with legacy BIOS and not UEFI. It also seems that
Patricks update as of March 2015 gave positive indications that a general fix
for com32-modules were possible.
>>
>>
>> It would have been nice to receive some update on both com32-module
compliance for the UEFI architecture as well as for the pxechn-module in
specific. We have a setup at my workplace that are dependant upon this working
and right now the only solution is to use legacy BIOS PXE-boot.
>>
>>
>> Is there any fix for this in the recently mentioned 6.04 pre-release
(soon to become release?)?
>
> No, I removed all modules with BIOSisms from UEFI builds like pxechn.c32.
>
> More importantly, Syslinux can't load arbitrary UEFI images yet.
>
> --
> -Gene

Hi,
________________________________________
From: Gene Cumm <gene.cumm at gmail.com>
Sent: Wednesday, March 16, 2016 00:56
To: Jan Frode J?ger
Cc: syslinux at zytor.com
Subject: Re: [syslinux] Updated status on UEFI compliant version of the
pxechn-module

On Tue, Mar 15, 2016 at 9:32 AM, Jan Frode J?ger
<jan.frode.jaeger at ntnu.no> wrote:

Without trying to figure out where data is stored or the possibility
of calls to manipulate the data, I can't speak for the possibility of
implementing anything that manipulates the options like pxechn.c32 for
UEFI.  I'd like to get UEFI chaining working first.

The shear length comparison speaks a lot for the differences.  Yes,
I've read through most of the PXE spec as it relates to the boot
process.  As bad as you think PXE is, consider how UEFI has been a
moving target in some respects.

What do you expect to PXE chainload?  If you could provide details on
what you hope to achieve, someone might be able to offer a suggestion
or workaround.

I understand. Just let me say that I appreciate all the work that has been done
on syslinux and that it is a great tool. I was only wanting to hear what your
plans were.

As goes the PXE chainloading - I am trying to redirect from a PXELINUX menu to a
WDS boot server with SCCM. So the option in my menu looks like this:

***SNIP***
label sccmserver
   menu label SCCM-server
   kernel /mods/pxechn.c32
   append 1.2.3.4::boot\x86\wdsnbp.com
***SNIP***

The IP here is of course just changed for this example. I have also tried to add
the "-W" parameter to pxechn, but without any change in result. It
always says "Error: Unable to retrieve first packet" and then
"Could not unpack packet".
> I just compiled up the 6.04-prerelease and can see that the pxechn-module
has been removed from the two efi-trees. As a sidenote: the NEWS-file in the
6.04-prerelease is missing information about changes introduced in it (seems to
be the file from 6.03).
NEWS has NOT been updated yet.
> As another sidenote and possible separate thread: since I couldn't get
UEFI to boot pxelinux 6.03 properly before I saw your dhcp options fix (vendor
encapsulated options), I implemented a simple PXE boot server ack-packet UDP
server in perl (the PXE client basically tries to perform a PXE boot server
discovery procedure). Works like a charm without the dhcp options under all the
Intel Boot Agent versions I tried - only need to set the mtftp-server address as
per recommendations in the PXE 2.1 spec. Is there any interest in me publishing
this boot server ack-packet script for others to use? Microsoft and others want
us to drop DHCP options and instead implement iphelpers in the router (if
clients and servers are on separate subnets), but shouldn't be necessary as
far as I can see. The origin of all this mess is again the PXE specification in
my opinion...
Intel Boot Agent?  Really?  I've NEVER seen mention of "Intel Boot
Agent" on UEFI.

I'd certainly be interested in this Perl script.

Sorry, misspeak - I have been working on this issue for an intensive period....
Of course the Intel Boot Agent (IBA) is under BIOS. Under UEFI PXE-boot I
developed the aforementioned boot server script to deal with the boot server
discovery being attempted by the UEFI PXE agent. It is based on some tcpdumps of
the network traffic between the tftp-server and an ack-packet from a WDS boot
server. Stripped away the proprietary dhcp options from the WDS boot server
though and used the definiton of an ack-packet in the PXE 2.1 specification as
soon as I understood what was going on. It is a very rudimentary script and was
only made to see if I could get the UEFI client to accept my Linux tftp-server
and its image-file (which was the syslinux.efi file for efi64 from version
6.03). How do you want the script - send it to your private email address?

Best,

    Jan-Frode

--
-Gene
> ________________________________________
> From: Gene Cumm <gene.cumm at gmail.com>
> Sent: Tuesday, March 15, 2016 13:42
> To: Jan Frode J?ger
> Cc: syslinux at zytor.com
> Subject: Re: [syslinux] Updated status on UEFI compliant version of the
pxechn-module
>
> On Tue, Mar 15, 2016 at 3:51 AM, Jan Frode J?ger <syslinux at
zytor.com> wrote:
>> Hi,
>>
>>
>> I have browsed through your syslinux archives and see that the issue of
an UEFI compliant version of the pxechn-module has come up several times:
>>
>>
>> http://www.syslinux.org/archives/2014-August/022611.html
>>
>> http://www.syslinux.org/archives/2015-March/023320.html
>>
>> http://www.syslinux.org/archives/2015-September/024231.html
>>
>>
>> Now the issue as I understand it is that the original pxechn-module has
been written to interface with legacy BIOS and not UEFI. It also seems that
Patricks update as of March 2015 gave positive indications that a general fix
for com32-modules were possible.
>>
>>
>> It would have been nice to receive some update on both com32-module
compliance for the UEFI architecture as well as for the pxechn-module in
specific. We have a setup at my workplace that are dependant upon this working
and right now the only solution is to use legacy BIOS PXE-boot.
>>
>>
>> Is there any fix for this in the recently mentioned 6.04 pre-release
(soon to become release?)?
>
> No, I removed all modules with BIOSisms from UEFI builds like pxechn.c32.
>
> More importantly, Syslinux can't load arbitrary UEFI images yet.
>
> --
> -Gene