similar to: [syslinux:master] core/pxe: extend parse_dhcp() for packet type

Displaying 20 results from an estimated 4000 matches similar to: "[syslinux:master] core/pxe: extend parse_dhcp() for packet type"

2015 Jun 21
1
[syslinux:master] core/pxe: extend parse_dhcp() for packet type
On Sun, Jun 21, 2015 at 11:12:07AM -0700, syslinux-bot wrote: > Commit-ID: 38e861ebf45a804bc5fbd74d9c19292822c84487 > Gitweb: http://www.syslinux.org/commit/38e861ebf45a804bc5fbd74d9c19292822c84487 > Author: Gene Cumm <gene.cumm at gmail.com> > AuthorDate: Sat, 20 Jun 2015 21:17:18 -0400 > Committer: Gene Cumm <gene.cumm at gmail.com> > CommitDate: Sat, 20
2015 Sep 12
2
pxelinux tries to load ldlinux.c32 from DHCP server, instead of next-server
On Sat, Sep 12, 2015 at 08:42:15AM -0400, Gene Cumm via Syslinux wrote: > On Sat, Sep 12, 2015 at 7:37 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > > On Sat, Sep 12, 2015 at 7:08 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > >> On Sat, Sep 12, 2015 at 5:54 AM, Teun Docter > >> <teun.docter at brightcomputing.com> wrote: > >>> On
2015 Sep 12
2
pxelinux tries to load ldlinux.c32 from DHCP server, instead of next-server
On Sat, Sep 12, 2015 at 6:37 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Sat, Sep 12, 2015 at 10:23 AM, Geert Stappers <stappers at stappers.nl> wrote: >> Euh, could this be reviewed: >> >> diff --git a/core/fs/pxe/dhcp_option.c b/core/fs/pxe/dhcp_option.c >> index 8d93a6a..b82e944 100644 >> --- a/core/fs/pxe/dhcp_option.c >> +++
2015 Sep 12
2
pxelinux tries to load ldlinux.c32 from DHCP server, instead of next-server
On Sat, Sep 12, 2015 at 7:08 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Sat, Sep 12, 2015 at 5:54 AM, Teun Docter > <teun.docter at brightcomputing.com> wrote: >> On 2015-09-12 04:58, Gene Cumm wrote: >>>> >>>> I've captured the following DHCP ACK: >>>> >>>> 10.141.20.1.bootps > 10.141.20.2.bootpc: [udp sum ok]
2015 Jan 11
3
PXE Booting EFI
>First, I was looking for the actual values.? >For a VM with (among other values): > config.version = "8" > virtualHW.version = "10" > ethernet0.virtualDev = "e1000" > guestOS = "rhel6-64" > firmware = "efi" > I see: > option-93 = 0x07 > option-60 ="PXEClient:Arch:00007:UNDI:003016" OK I take
2015 Jun 11
2
[PATCH 0/1] Network UEFI PXE DHCP/proxyDHCP fix
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
2015 Jun 03
5
[PATCH 0/1] EFI PXE DHCP/proxyDHCP issues fix
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).
2015 Feb 20
1
[PATCH 0/1] EFI image booting capabilities
>> +? ? if(&mode->ProxyOfferReceived) >> +? ? ? ? parse_dhcp(&mode->ProxyOffer.Dhcpv4,pkt_len); >> +? ? else > > I think that change should go into another commit. > Geert Stappers You may be right; but as I've said, all the testing was conducted on PXE (proxyDHCP) environments where those lines are mandatory to my patch. I just tried to keep things
2015 Jan 11
0
PXE Booting EFI
On Sun, Jan 11, 2015 at 10:32 AM, Patrick Masotta <masottaus at yahoo.com> wrote: > >>First, I was looking for the actual values. >>For a VM with (among other values): > >> config.version = "8" >> virtualHW.version = "10" >> ethernet0.virtualDev = "e1000" >> guestOS = "rhel6-64" >> firmware =
2015 Feb 20
0
[PATCH 0/1] EFI image booting capabilities
On Fri, Feb 20, 2015 at 05:08:26AM -0800, Patrick Masotta via Syslinux wrote: > 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
2015 Sep 12
0
pxelinux tries to load ldlinux.c32 from DHCP server, instead of next-server
On Sat, Sep 12, 2015 at 10:23 AM, Geert Stappers <stappers at stappers.nl> wrote: > On Sat, Sep 12, 2015 at 08:42:15AM -0400, Gene Cumm via Syslinux wrote: >> On Sat, Sep 12, 2015 at 7:37 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> > On Sat, Sep 12, 2015 at 7:08 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> >> On Sat, Sep 12, 2015 at 5:54 AM,
2015 Oct 07
4
UEFI: Failed to load ldlinux.e64/ldlinux.e32
On Wed, Oct 7, 2015 at 6:09 PM, Gene Cumm <gene.cumm at gmail.com> wrote: >> -----Original Message----- >> From: Gene Cumm [mailto:gene.cumm at gmail.com] >> Sent: Wednesday, October 07, 2015 4:43 PM >> To: For discussion of Syslinux and tftp-hpa; Geert Stappers >> Subject: Re: [syslinux] UEFI: Failed to load ldlinux.e64/ldlinux.e32 >> >> On Wed, Oct
2014 Sep 25
1
UEFI PXE / split config / TFTP attempted to DHCP server, not TFTP server
>Date: Sun, 21 Sep 2014 22:19:12 -0400 >From: Gene Cumm <gene.cumm at gmail.com> >To: Spike White <spikewhitetx at gmail.com> >Cc: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com> >Subject: Re: [syslinux] UEFI PXE / split config / TFTP attempted to > DHCP server, not TFTP server >Message-ID: >
2015 Feb 20
6
[PATCH 0/1] EFI image booting capabilities
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 ---
2015 Jun 12
0
[PATCH 0/1] Network UEFI PXE DHCP/proxyDHCP fix
On Thu, Jun 11, 2015 at 4:02 PM, <jeff_sloan at selinc.com> wrote: > 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. 1) In commit 2e266c35, I proposed using UseDefaultAddress. As I
2015 Jun 09
2
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
2015 Mar 14
0
[PATCH 0/1] EFI access from Com32 modules
This patch adds to Com32 modules the capabilities of accessing the EFI environment The idea is simple, the EFI parameters "image" and "table" received by syslinux.efi's efi_main() are stored in the "firmware" structure, next they are retrieved from the Com32 module which is linked against the gnu-efi static library. The Com32 module can use the EFI
2015 Jun 26
3
[PATCH 0/1] Network UEFI PXE DHCP/proxyDHCP fix
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:
2015 Jan 19
0
PXE Booting EFI
On Mon, Jan 19, 2015 at 3:09 PM, Patrick Masotta <masottaus at yahoo.com> wrote: > >> EFI has proven to be more robust. The catch >> here is order. The >> ProxyOffer data must >> take precedence over the PxeReply data but both >> of them probably need to be parsed. > > Not really; If you parse both "next server" from the > last parsed
2015 Jan 19
2
PXE Booting EFI
> EFI has proven to be more robust.? The catch > here is order.? The > ProxyOffer data must > take precedence over the PxeReply data but both > of them probably need to be parsed. Not really; If you parse both "next server" from the last parsed packet (PxeReply) will overwrite the value gathered from the ProxyOffer and that leads to "Nest-server"= DHCP Server IP