Syslinux - Jun 2016 - Locally-loaded syslinux.efi with remote HTTP config?

On Sat, Jun 18, 2016 at 4:09 AM, Geert Stappers via Syslinux
<syslinux at zytor.com> wrote:
> On Fri, Jun 17, 2016 at 07:27:17PM -0500, Alexander Perlis via Syslinux
wrote:
>> Question:
>>   If syslinux.efi is loaded locally off USB rather than via an EFI
>> PXE option ROM boot, but on a client whose EFI firmware has TCP
>> support, should that locally-booted syslinux.efi be able to process
>> HTTP URLs? Initial experiments indicate "no", but why not?
Simple.  First, the entire network subsystem isn't ready and second
this requires multifs.
>> Purpose:
>>   My TCP-capable EFI client is on a subnetwork with broken DHCP not
>> under my control, so I can't achieve a traditional network PXE boot
>> to my PXE server;
>
> How broken that DHCP server setup is, is unclear to me.
>
> Question: Has Proxy-DHCP been considered?
>
> At http://ipxe.org/gsoc#proxydhcp_server is good explainatin
> of Proxy-DHCP
"not under my control" sounds like a perfect fit for ProxyDHCP.
ProxyDHCP can be very selective about only providing a response to
previously known clients, implementation-dependent, supersceding DHCP
responses for boot data while the client system uses the DHCP server
for its address data.  It's commonly accepted that the PXE spec
reversed priority.
>> as a solution, I seek a simple USB-based shim that
>> will boot locally and then chain me over to my PXE server. Attempts
>> with ipxe snponly weren't immediately successful,
>
> I still feel the need to hint
> to http://www.syslinux.org/archives/2016-May/025198.html
You won't be able to use snponly.efi by itself without also building
in a script to point things to the right server then chainload
syslinux.efi.
> Below the full text of the original poster. Nothing deleted
> because I may not have understand what is wanted.
>
>
>> meanwhile I
>> started wondering whether I can just use syslinux.efi locally to
>> achieve this? My syslinux.efi is configured thus:
>>
>>   -a next-server ip.of.pxe.server
>>
>>   -a config-file name.of.pxe.server.config
>>
>>   -a path-prefix http://ip.of.pxe.server/
syslinux.efi was not loaded from PXE so these should be ignored.
>> I would guess under local boot that next-server is ignored, but
>> path-prefix should still come into play, no? When syslinux.efi sees
>> an "http" URL after having been booted via an actual network
EFI PXE
>> option ROM, instead of trying to call an underlying PXE stack that
UEFI is very different.  There's no option ROM nor PXE stack.
Generally speaking, the underlying UEFI system has to get NIC drivers
(commonly built-in) and initialize the network through a round of DHCP
or static configuration.  I don't know of any UEFI overview/tutorial
without Googling for one.
>> would talk only TFTP, doesn't syslinux.efi bypass that and instead
>> use the underlying EFI firmware's TCP capability to do an HTTP
>> transfer? So then in principle couldn't it also do that whether or
Actually, for TFTP syslinux.efi uses UDPv4Sb instead of one of the TFTP methods.
>> not an underlying unneeded PXE stack were even present in the first
>> place? In other words, when syslinux.efi is booted locally, the EFI
>> firmware still has TCP capability, so why can't syslinux.efi
process
>> the HTTP URL?
See above.

-- 
-Gene

On 06/18/16 03:50, Gene Cumm via Syslinux wrote:
> 
> UEFI is very different.  There's no option ROM nor PXE stack.
> Generally speaking, the underlying UEFI system has to get NIC drivers
> (commonly built-in) and initialize the network through a round of DHCP
> or static configuration.  I don't know of any UEFI overview/tutorial
> without Googling for one.
> 
Actually, for an external NIC there is still an option ROM.  The UEFI
network stack is referred to as "PXE" even though it is nothing like
the
BIOS PXE stack.
>>> would talk only TFTP, doesn't syslinux.efi bypass that and
instead
>>> use the underlying EFI firmware's TCP capability to do an HTTP
>>> transfer? So then in principle couldn't it also do that whether
or
> 
> Actually, for TFTP syslinux.efi uses UDPv4Sb instead of one of the TFTP
methods.
The real question is whether or not the UEFI firmware actually
initializes the network stack (or if there is a way to do so that
actually works on real systems) when not booted from the network.  I
will try to research that question.

	-hpa

On Tue, Jun 21, 2016 at 5:33 PM, H. Peter Anvin via Syslinux
<syslinux at zytor.com> wrote:
> On 06/18/16 03:50, Gene Cumm via Syslinux wrote:
>>
>> UEFI is very different.  There's no option ROM nor PXE stack.
>> Generally speaking, the underlying UEFI system has to get NIC drivers
>> (commonly built-in) and initialize the network through a round of DHCP
>> or static configuration.  I don't know of any UEFI
overview/tutorial
>> without Googling for one.
>>
>
> Actually, for an external NIC there is still an option ROM.  The UEFI
> network stack is referred to as "PXE" even though it is nothing
like the
> BIOS PXE stack.
I misspoke.  I meant there's no option ROM application executed from
the option ROM on the NIC like BIOS.  The UEFI system should be
loading a NIC driver from the option ROM, if prepared properly with a
driver for the proper architecture.
>>>> would talk only TFTP, doesn't syslinux.efi bypass that and
instead
>>>> use the underlying EFI firmware's TCP capability to do an
HTTP
>>>> transfer? So then in principle couldn't it also do that
whether or
>>
>> Actually, for TFTP syslinux.efi uses UDPv4Sb instead of one of the TFTP
methods.
>
> The real question is whether or not the UEFI firmware actually
> initializes the network stack (or if there is a way to do so that
> actually works on real systems) when not booted from the network.  I
> will try to research that question.
When poking around with the UEFI shells, the systems I've seen appear
to have the bindings in place but just lack IPv4 addressing.  For
single-NIC systems, this should be relatively easy.

-- 
-Gene