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

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?

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; 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, 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/

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 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 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?

Thanks,
Alex

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?
> 
> 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 

> 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


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/
> 
> 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
> 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
> 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?
> 
> Thanks,
> Alex
> _______________________________________________
> Syslinux mailing list

Groeten
Geert Stappers
-- 
Leven en laten leven

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