[syslinux] [PATCH 0/1] EFI PXE DHCP/proxyDHCP issues fix

[Gene Cumm]

On Mon, May 25, 2015 at 6:25 PM, Patrick Masotta <masottaus at yahoo.com> wrote:
>
>  >>>
>  > DhcpDiscover.Dhcpv4 gets populated at the "Dhcp4SendDiscover" event
>
>  Syslinux on EFI won't be
>  sending these packets.  The underlying EFI
>  framework will.
>  <<<
>
> Sure but the idea is to parse the packets that have the info sent by the DHCP Server...

It is true that we need the data that the DHCP/PXE servers sent.

>>>>
>  DhcpAck and DhcpOffer
>  shouldn't contain the details.  DhcpDiscover and
>  DhcpRequest should.
> <<<
>
> Why do you think so?
> The client IP, the TFTP server IP, etc are contained
> on DHCP Server sent packets.

This is true.  This is not disputed.

>>>>
>  In the current code,
>  there's three calls to parse_dhcp().
>
>  1) With DhcpDiscover.  This is intended to get
>  the client identifiers
>  that the servers
>  never bother returning like DHCP option 60 (Vendor
>  Class
>  Identifier).
>
>  2) With DhcpAck.  This
>  is intended to get the server-provided
>  parameters for basic network interactions like
>  IPv4 address, subnet
>  mask, gateway and
>  DNS.
>  3) With PxeReply.  The intention here
>  was to grab the advanced
>  server-provided
>  parameters for network booting like the file and
>  server to grab it from.
>
>  The code of #3 is currently wrong as it ignores
>  ProxyOffer.  I'm not
>  arguing this needs
>  to be patched.
>
>  Your patch
>  ignores the client identifiers (call #1).
>  <<<
>
> I'm running my patch every day and "so far" it works very well.
> I do not recall now the need to parse option 60 on the client packet,
> it should only contain "PXEClient" right?

Not just.  On a BIOS client, 60 is "PXEClient:Arch:00000:UNDI:002001".
On an EFI x86-64 client, I see "PXEClient:Arch:00007:UNDI:003016".
Option 93, a binary architecture indicator, and 97, UUID, will likely
not be present in server responses.

The question is mostly "Do we need to parse DhcpDiscover or
DhcpRequest when we're already parsing DhcpAck?"  My answer is quite
simply I don't know without searching code.  In all likelihood, it's
not needed except by a COM32 that would request the packet to parse
itself.

This leads to another.  "Does it hurt to parse it?"  Again, it should
be fine as it's been that way for some time.

-- 
-Gene