[syslinux] Locally-loaded syslinux.efi with remote HTTP config?

Gene Cumm gene.cumm at gmail.com
Sat Jun 18 03:50:07 PDT 2016


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


More information about the Syslinux mailing list