On Sun, Jun 7, 2015 at 5:09 PM, Patrick Masotta <masottaus at yahoo.com> wrote:>>>> > Patrick, I think I've been able to figure out some missing details > about your VMware Workstation tests. For a proxyDHCP, > I'm using dnsmasq. Could you try to confirm your test was the > same basic setup? > > On VMware Workstation 10 with a VMHWv10 VM set to EFI > firmware for x64, I've been able to get mixed results, depending on if agateway is provided. > > With a VMHWv9 VM, I see what appear to be the issues you see. > > VMHWv10, NAT: Boot Service Discover (a BOOTP style request) > sent to the wrong MAC address (MAC address of gateway) > > VMHWv10, Host-Only, 6.03: success > > VMHWv9, NAT: Same as VMHWv10 > > VMHWv9, Host-Only, 6.03: Syslinux appears deaf; no ARP > response, no TFTP acknowledgement after receiving the first packet of a > file request. > > VMHWv9, Host-Only, Commit 81eeaa3: Same as 6.03. > > -- > -Gene > <<< > > Are you testing with the patch applied or without? > As clients I'm using Workstation 10 VMs (32/64bit) and a real Toshiba notebook. > When the client is a VM the DHCP server is VMware's, When the client is a real > notebook the DHCP server is an external Netgear router. In any case the proxyDHCP is Serva. > > Best, > PatrickIt appears I was unclear about which I suspected as being similar to your tests, specifically VMHWv9 on the Host-Only network. It is possible that on Windows or with the Serva application, things act differently. Commit 81eeaa3 contains the variant of your patch that I thought I had talked about. https://github.com/geneC/syslinux.git git://github.com/geneC1/syslinux.git https://github.com/geneC/syslinux/commit/81eeaa3ea93ef124d4308f622ee29673e534dc0c I'm going to be trying your patch as-is next but I'm doubting it'll influence things. -- -Gene
On Mon, Jun 8, 2015 at 8:19 PM, Gene Cumm <gene.cumm at gmail.com> wrote:> On Sun, Jun 7, 2015 at 5:09 PM, Patrick Masotta <masottaus at yahoo.com> wrote: >>>>> >> Patrick, I think I've been able to figure out some missing details >> about your VMware Workstation tests. For a proxyDHCP, >> I'm using dnsmasq. Could you try to confirm your test was the >> same basic setup? >> >> On VMware Workstation 10 with a VMHWv10 VM set to EFI >> firmware for x64, I've been able to get mixed results, depending on if agateway is provided. >> >> With a VMHWv9 VM, I see what appear to be the issues you see. >> >> VMHWv10, NAT: Boot Service Discover (a BOOTP style request) >> sent to the wrong MAC address (MAC address of gateway) >> >> VMHWv10, Host-Only, 6.03: success >> >> VMHWv9, NAT: Same as VMHWv10 >> >> VMHWv9, Host-Only, 6.03: Syslinux appears deaf; no ARP >> response, no TFTP acknowledgement after receiving the first packet of a >> file request. >> >> VMHWv9, Host-Only, Commit 81eeaa3: Same as 6.03. >> >> -- >> -Gene >> <<< >> >> Are you testing with the patch applied or without? >> As clients I'm using Workstation 10 VMs (32/64bit) and a real Toshiba notebook. >> When the client is a VM the DHCP server is VMware's, When the client is a real >> notebook the DHCP server is an external Netgear router. In any case the proxyDHCP is Serva. >> >> Best, >> Patrick > > It appears I was unclear about which I suspected as being similar to > your tests, specifically VMHWv9 on the Host-Only network. It is > possible that on Windows or with the Serva application, things act > differently. > > Commit 81eeaa3 contains the variant of your patch that I thought I had > talked about. > > https://github.com/geneC/syslinux.git > git://github.com/geneC1/syslinux.git > > https://github.com/geneC/syslinux/commit/81eeaa3ea93ef124d4308f622ee29673e534dc0c > > I'm going to be trying your patch as-is next but I'm doubting it'll > influence things. > > -- > -GeneAnd I stand corrected Patrick. Apparently some clients are stuffing bad values into packets and moving the code to save the MAC resolves the deafness I observed. Commit 8a00e49 is the change. -- -Gene
>>>And I stand corrected Patrick.? Apparently some clients are stuffing bad values into packets and moving the code to save the MAC resolves the deafness I observed. Commit 8a00e49 is the change. -- -Gene <<< OK; I was about to ask you a few wiershark captures... I looked at the last commit and I think if (mode->PxeReplyReceived) pkt_v4 = &mode->PxeReply.Dhcpv4; else if (mode->ProxyOfferReceived) pkt_v4 = &mode->ProxyOffer.Dhcpv4; should be replaced by if (mode->PxeReplyReceived) pkt_v4 = &mode->PxeReply.Dhcpv4; else if (mode->ProxyOfferReceived) pkt_v4 = &mode->ProxyOffer.Dhcpv4; else pkt_v4 = &mode->DhcpAck.Dhcpv4; this code is used in C:\UDK2014.SP1.P1.Complete\MyWorkSpace\NetworkPkg\UefiPxeBcDxe\PxeBcBoot.c / PxeBcDhcp4BootInfo() when looking for boot info. I agree it is not 100% clear but it could be necessary on non proxyDHCP situations. i.e when the PXE info is contained within the DHCP OFFER/ACK I do not know if in that particular case some FWs probably do not populate the ProxyOffer pkt. In those cases the last "else" would be necessary. Best, Patrick