similar to: EFI and proxyDHCP: setups

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

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

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

The UEFI PXE boot DHCP/proxyDHCP issue is very timely. I am working on that very topic now. Our scenario is a manufacturing environment set up to format and load/install custom hard drive images in our systems. Our environment: This is a manufacturing floor setup where we build computers for our customers. We have two servers and a client in the mix, all connected via Ethernet (IPv4 only).

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

>>> I'm just debating what's the best algorithm here.? It would seem if the LoadeImage's DeviceHandle provides UDPv4Sb, use it as it's guaranteed to be the same interface.? Otherwise, we need a MNPSb (EFI_MANAGED_NETWORK_SERVICE_BINDING) that provides UDPv4Sb across the same interface.? Presumably it should also provide TCPv4Sb (rather than being on a separate

from: Jeff Sloan <jeff_sloan at selinc.com> Update UEFI PXE proxyDHCP handling updated. This patch is based on commit ID 8a00e49 Updated pxe.c and udp.c to incorporate feedback.In addition to the previous modifications: pxe.c: Changed to use ProxyOffer Packet and added client ip from PxeReply into temp packet for parsing. Left all existing cached packets untouched. udp.c:

Michael, If you actually get virtualbox PXE booting via UEFI, please let us know how. I spent about two weeks trying to get this to work. This virtualbox PXE booting via UEFI appears so new, it was poorly documented. As of two months ago, when I was doing all this testing. Allegedly, it has experimental support for UEFI PXE boot, if you have Intel NICs. (It uses the UEFI boot code from the

>>> Lovely, the ServiceBindings are on a handle that resembles the NIC while the Pxebc is IP-type specific.? Looks like we should try to do a ServiceBinding based on Pxebc but fall back to MAC-based searching, saving all 3 handles, the image handle, Pxebc handle, and ServiceBinding handle.? Presumably the UDP and TCP handles _should_ be the same... -- -Gene <<< OK now it

On Wed, Jun 3, 2015 at 3:25 PM, Jeff via Syslinux <syslinux at zytor.com> wrote: > The UEFI PXE boot DHCP/proxyDHCP issue is very timely. I am working on > that very topic now. > Our environment: > The real DHCP server supplies client ip address only. Everything else > comes from proxyDHCP. > Problem 2: > > The next problem is packet parsing and incomplete ip

On Tue, Jun 9, 2015 at 9:05 AM, Patrick Masotta <masottaus at yahoo.com> wrote: >>>> > 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

>>> The real DHCP server supplies client ip address only. Everything else comes from proxyDHCP. The proxyDHCP server supplies boot file name, boot file (syslinux.efi), boot loader (ldlinux.e64), config file, tinycore and OS image files. <<< This is not completely correct: your DHCP server provides an IP and your proxyDHCP server only processes a complementary DHCP

>>> > 1) There's not "any" SB protocol present (Elitebook 8460p/2560p) The only solution for these is to use our own stack (likely full TCP/IP like lwIP) and connect to the Net GUID (EFI_SIMPLE_NETWORK_PROTOCOL).? Does the handle for Pxebc contain a Net?? >>> It does contain a Net but there are 2 issues with SNP: 1) The interface is different than

This patch adds to the core EFI image booting capabilities. It was tested on VMware EFI clients and HP Elitebook EFI notebooks, only on PXE environments but it should work on non-PXE scenarios as well. Feedback appreciated. Best, Patrick Signed-off-by: Patrick Masotta <masottaus at yahoo.com> --- diff -uprN a/com32/elflink/ldlinux/execute.c b/com32/elflink/ldlinux/execute.c ---

from: Jeff Sloan <jeff_sloan at selinc.com> Update UEFI PXE proxyDHCP handling. This patch is based on commit ID 8a00e49 Modify two files to specify valid ip addresses. These files are efi/pxe.c and efi/udp.c. In efi/pxe.c: In net_parse_dhcp function. If ProxyOffer has been received, start with DhcpAck packet since it is the most complete. This requires a minimum of changes to the

Hi: First - pxelinux works great - got it up and running with few problems. However - I ran into a snag, I am assuming I have a configuration issue. Here are the details. Using: syslinux-1.75 dhcp-3.0pl1 tftp-hpa-0.29 A lot of what I have done is from: http://frank.harvard.edu/~coldwell/diskless dhcpd.conf: # DHCP configuration file for DHCP ISC 3.0 ddns-update-style

On Fri, Jun 26, 2015 at 10:15 AM, <jeff_sloan at selinc.com> wrote: > Will do, Gene. I'll let you (and the mailing list) know. Jeff, what's your status? -- -Gene > From: Gene Cumm <gene.cumm at gmail.com> > To: jeff_sloan at selinc.com, > Cc: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>, > masotta <masottaus

On Fri, Jun 26, 2015 at 8:58 AM, <jeff_sloan at selinc.com> wrote: > from: Jeff Sloan <jeff_sloan at selinc.com> > > Update UEFI PXE proxyDHCP handling updated. > > This patch is based on commit ID 8a00e49 This commit is outdated. Could you try commit ID 23b2707b as-is first? Thanks. > Updated pxe.c and udp.c to incorporate feedback.In addition to the previous

On Mon, Jun 8, 2015 at 4:07 PM, <jeff_sloan at selinc.com> wrote: > Gene, > Where do you keep the development tree? It's probably staring me in the face > but I can't find any updates beyond initial 6.03. Officially listed at http://www.syslinux.org/wiki/index.php/Development The primary repo at kernel.org is behind. The development repo at zytor.com is up to date but

Hello, I did join 2 sites using an IPSEC tunnel, and made one domain trust the other (2 small Samba DC based domains with about 10 users in each) I first had resolving issues until I decided to keep only one WINS server for both networks (though this is still an issue to me because if for any reason the tunnel is broken, I have no longer WINS on one side). Finally here is my setup : Network A