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

[Patrick Masotta]

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

Well then why do we need to parse a packet like DhcpDiscover which is sent by the client?

 
 >>>
 > 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.
<<<
I know, I know, but that Arch & UNDI PXE info is never used not even by 
PXE servers... as you say the client arch is really defined by DHCP option 93.
Do we need to know DHCP option 93 in syslinux.efi?
I do not think so; syslinux.efi architecture is defined at compile time and we get 
2 different binaries (32 and 64 bits). Do we need more than that?

>>>
 The question is mostly "Do we need to parse DhcpDiscover or
 DhcpRequest when we're already parsing DhcpAck?"  
<<<
I think we need to parse neither...

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

I agree; let's see the code, but let's also think in advance
why would we need the info contained on client sent DHCP Discover or Request
packets when we are really looking for info provided by the DHCP/PXE server instead?

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

The DHCP parsing call "n" overwrites the data gathered on call "n-1"... 
then it looks like it shouldn't hurt even when I think that makes no much 
sense. Plus I'm running modded code (so far) w/o problems.

Best,
Patrick