search for: net_parse_dhcp

...;<< Hi Gene have you seen this thread? http://www.syslinux.org/archives/2015-April/023436.html continued here http://www.syslinux.org/archives/2015-May/023443.html Cao's patch try to solve the same multi-NIC issue you are dealing with; Your approach detect's the right NIC at pxe.c\net_parse_dhcp(void) but it is also necessary to detect the right NIC again at main.c\efi_create_binding() as explained here. http://www.syslinux.org/archives/2015-May/023453.html Cao's patch fails doing this because it relies on certain assumptions on handle "order" that are not correct. I'm...

...t; continued here > http://www.syslinux.org/archives/2015-May/023443.html Apparently I tagged it in my email but never got around to reading it yet. > Cao's patch try to solve the same multi-NIC issue you are dealing with; > > Your approach detect's the right NIC at > pxe.c\net_parse_dhcp(void) > but it is also necessary to detect the right NIC again at > main.c\efi_create_binding() > as explained here. > http://www.syslinux.org/archives/2015-May/023453.html > Cao's patch fails doing this because it relies on certain assumptions on > handle "order" th...

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 packet except that it contains NULL server ip so populate server from ProxyOffer packet. The information is loaded into pkt_v4 and then parsed. In efi/u...

On Thu, Jun 25, 2015 at 7:28 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Thu, Jun 25, 2015 at 11:54 AM, Patrick Masotta <masottaus at yahoo.com> wrote: > >> Yes I know what you mean; >> "I think" the handle of the running image (our code) has a "path" telling us where >> was laded from. That would solve this thing. > > I just

...takes when deciding where the PXE server is located. syslinux.efi is taking the next-server IP from an answer from a DHCP server that did not identified itself as a PXE server (no option 60). It looks like a bug to me. I think I "kind" of fixed the bug; at syslinux-6.03/efi/pxe.c void net_parse_dhcp(void) { ... //patmod start if(&mode->ProxyOfferReceived) parse_dhcp(&mode->ProxyOffer.Dhcpv4, pkt_len); else //patmod end parse_dhcp(&mode->PxeReply.Dhcpv4, pkt_len); Print(L"\n"); ... } just add the code surrounded by comments the idea i...

...39;t utilize the default routing otherwise. This may require more code to distinguish subnet-local versus remote. Looks like the thread starting at http://www.syslinux.org/archives/2013-November/021039.html 2) Why not touch efi/tcp.c also which also uses UseDefaultAddress? > 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 packet except that > it contains NULL server ip so populate server from ProxyOffer packet. The > information is loaded into pkt_v4 and t...

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 =

>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

...amp;pxe_fs_ops; > + pxe_handle = info->DeviceHandle; > } > > /* setup timer for boot menu system support */ > diff --git a/efi/pxe.c b/efi/pxe.c > index 443ab47..82cdee4 100644 > --- a/efi/pxe.c > +++ b/efi/pxe.c > @@ -93,20 +93,13 @@ void net_parse_dhcp(void) > EFI_PXE_BASE_CODE *bc; > unsigned int pkt_len = sizeof(EFI_PXE_BASE_CODE_PACKET); > EFI_STATUS status; > - EFI_HANDLE *handles = NULL; > - UINTN nr_handles = 0; > uint8_t hardlen; > uint32_t ip; > char dst[256]; > + UINTN i =...

...ot_linux, + .boot_efi = efi_boot_efi, + .clear_screen = efi_clear_screen, .vesa = &efi_vesa_ops, .mem = &efi_mem_ops, }; diff -uprN a/efi/pxe.c b/efi/pxe.c --- a/efi/pxe.c 2014-10-06 10:27:44.000000000 -0600 +++ b/efi/pxe.c 2015-02-18 19:39:43.118182728 -0700 @@ -154,7 +154,12 @@ void net_parse_dhcp(void) * Get the boot file and other info. This lives in the CACHED_REPLY * packet (query info 3) */ - parse_dhcp(&mode->PxeReply.Dhcpv4, pkt_len); + + if(&mode->ProxyOfferReceived) + parse_dhcp(&mode->ProxyOffer.Dhcpv4, pkt_len); + else + parse...

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

...ao via Syslinux <syslinux at zytor.com> wrote: > PXE booting in UEFI mode of HP Proliant Gen9 will fail if the nic port > used is not the first one enumerated. > Based on syslinux 6.03, several modifications have to be made in the > EFI supporting codes. > 1. The function "net_parse_dhcp". Instead of using the first handle > that returns EFI_SUCCESS, a check on the DhcpAckReceived is made. The > index and the total number handles are saved in global variables. > 2. Function "efi_create_binding". Instead of using the first handle > that returns EFI_SUCCESS...

...evice Handle" supporting all those protocols. (clearly said at UEFI_Driver_Writer_Guide_V1.0.1_120308.pdf) 2) about your last commit 2.1) I think I found a couple of issues check them corrected at https://github.com/ppatpat/syslinux/ a) a missing return; on an error condition at efi/pxe.c\net_parse_dhcp() b) you close a protocol before creating its child at efi/main.c\efi_create_binding() 2.2) I think "image_DeviceHandle" instead of "pxe_DeviceHandle" produces a code easier to follow; specially when we end up using that handle to create a TCP4 or UDP4 child... Best, Patric...

Signed-off-by: Beno?t Allard <benoit.allard at greenbone.net> --- efi/fio.h | 9 --------- 1 file changed, 9 deletions(-) diff --git a/efi/fio.h b/efi/fio.h index 65fff8d..a1bfe68 100644 --- a/efi/fio.h +++ b/efi/fio.h @@ -11,15 +11,6 @@ #define MAX_EFI_ARGS 64 #define WS(c16) (c16 == L' ' || c16 == CHAR_TAB) -/* VPrint is not in export declarations in gnu-efi lib yet

...XE > server is located. syslinux.efi is taking the next-server IP from an answer from a DHCP server that > did not identified itself as a PXE server (no option 60). It looks like a bug to me. > > I think I "kind" of fixed the bug; > at syslinux-6.03/efi/pxe.c > > void net_parse_dhcp(void) > { > ... > > //patmod start > if(&mode->ProxyOfferReceived) > parse_dhcp(&mode->ProxyOffer.Dhcpv4, pkt_len); > else > //patmod end > > parse_dhcp(&mode->PxeReply.Dhcpv4, pkt_len); > Print(L"\n"); > &gt...

...t; > Feedback appreciated. > > Best, > Patrick > > Signed-off-by: Patrick Masotta <masottaus at yahoo.com> <bigsnip/> > --- a/efi/pxe.c 2014-10-06 10:27:44.000000000 -0600 > +++ b/efi/pxe.c 2015-02-18 19:39:43.118182728 -0700 > @@ -154,7 +154,12 @@ void net_parse_dhcp(void) > * Get the boot file and other info. This lives in the CACHED_REPLY > * packet (query info 3) > */ > - parse_dhcp(&mode->PxeReply.Dhcpv4, pkt_len); > + > + if(&mode->ProxyOfferReceived) > + parse_dhcp(&mode->ProxyOffer....

...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 (wrong) Order: at syslinux-6.03/efi/pxe.c void net_parse_dhcp(void) { ... parse_dhcp(&mode->PxeReply.Dhcpv4, pkt_len); //genemod start if(&mode->ProxyOfferReceived) parse_dhcp(&mode->ProxyOffer.Dhcpv4, pkt_len); //genemod end Print(L"\n"); ... } Though I'm trying to think of a DHCP option that wouldn&...

> 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

From: Sylvain Gault <sylvain.gault at gmail.com> I don't know if I should merge those trivial warning fix into one commit. I can reformat it as requested. Those are a few warning fixes for the efi part. The code involved has mainly been introduced in recent commits. Sylvain Gault (3): efi: fix warnings about argument types efi: fix pointer-type mismatch assigment warning efi: fix

...dle to the device that loaded Syslinux, in this case a NIC plus IP-stack (IPv4 or IPv6). > 2) about your last commit > 2.1) I think I found a couple of issues check them corrected at > https://github.com/ppatpat/syslinux/ > > a) a missing return; on an error condition at efi/pxe.c\net_parse_dhcp() > b) you close a protocol before creating its child at efi/main.c\efi_create_binding() Rewrote the commit messages and it's in at commit ID 5186539 > 2.2) I think "image_DeviceHandle" instead of "pxe_DeviceHandle" produces a code easier to follow; > specially...