search for: siaddr

>On Sat, Sep 12, 2015 at 6:37 PM, Gene Cumm <gene.cumm at gmail.com> wrote: >> >... > >> Something like this would be preferable except it's not quite so >> simple. We'd need to not store BOOTP siaddr before parsing. Store a >> pointer to the string during parsing if serverip is unset. After all >> parsing, if the pointer is set, attempt to resolve then set serverip. >> Last, if serverip is not set, copy siaddr to serverip. > >Perhaps a more important question is if ANY...

...if (over_load & 2) >> parse_dhcp_options(dhcp->sname, 64, 0); >> + >> + /* What about option 66, tftserver_name ? FIXME */ >> } > > Something like this would be preferable except it's not quite so > simple. We'd need to not store BOOTP siaddr before parsing. Store a > pointer to the string during parsing if serverip is unset. After all > parsing, if the pointer is set, attempt to resolve then set serverip. > Last, if serverip is not set, copy siaddr to serverip. Perhaps a more important question is if ANY PXE implementation...

...tions(dhcp->sname, 64, 0); >> >> + >> >> + /* What about option 66, tftserver_name ? FIXME */ >> >> } >> > >> > Something like this would be preferable except it's not quite so >> > simple. We'd need to not store BOOTP siaddr before parsing. Store a >> > pointer to the string during parsing if serverip is unset. After all >> > parsing, if the pointer is set, attempt to resolve then set serverip. >> > Last, if serverip is not set, copy siaddr to serverip. >> >> Perhaps a more impo...

...cted, exposed. Someone thought we should parse DHCP option > > 54 for the next server to use which is completely wrong. A DHCP, > > proxyDHCP or PXE server could point clients to other addresses but > > always record their own IP in option 54. It should use BOOTP field > > siaddr, resolve DHCP option 66 or resolve BOOTP field sname. Since we > > only pay attention to siaddr for now, this is a minimal change to fix. > } This patch should help: > > > diff --git a/core/fs/pxe/dhcp_option.c b/core/fs/pxe/dhcp_option.c > index 8d93a6a..5cc0ef7 100644 &gt...

...rect. That's what's working at my house. I tried that at work. Dotted decimal. Not working. Also tried short hostname, FQDN. No love. >> bootfile-name (67) -- set UEFI NBP's full path > >Same as filename? Yes. >Have you tried skipping options 66/67 or setting siaddr/file to 0 as >additional data points to report to Dell? I have tried the first. siaddr/file only. I have not tried the second. Let me try. OK, just tried. Same. Good suggestion however. >> (BTW, I'm using the embedded Broadcom NIC that comes w/ the R710). I have >> flash...

...o file a bug on your behalf. As I suspected, exposed. Someone thought we should parse DHCP option 54 for the next server to use which is completely wrong. A DHCP, proxyDHCP or PXE server could point clients to other addresses but always record their own IP in option 54. It should use BOOTP field siaddr, resolve DHCP option 66 or resolve BOOTP field sname. Since we only pay attention to siaddr for now, this is a minimal change to fix. -- -Gene

...; parse_dhcp_options(dhcp->sname, 64, 0); > >> + > >> + /* What about option 66, tftserver_name ? FIXME */ > >> } > > > > Something like this would be preferable except it's not quite so > > simple. We'd need to not store BOOTP siaddr before parsing. Store a > > pointer to the string during parsing if serverip is unset. After all > > parsing, if the pointer is set, attempt to resolve then set serverip. > > Last, if serverip is not set, copy siaddr to serverip. > > Perhaps a more important question is i...

...Someone thought we should parse DHCP option >> > 54 for the next server to use which is completely wrong. A DHCP, >> > proxyDHCP or PXE server could point clients to other addresses but >> > always record their own IP in option 54. It should use BOOTP field >> > siaddr, resolve DHCP option 66 or resolve BOOTP field sname. Since we >> > only pay attention to siaddr for now, this is a minimal change to fix. >> > } This patch should help: >> >> >> diff --git a/core/fs/pxe/dhcp_option.c b/core/fs/pxe/dhcp_option.c >> index 8...

The following changes since commit a35dce33744f649fdbc0af0da664554cccaa8248: H. Peter Anvin (1): Merge remote-tracking branch 'hdt/master' are available in the git repository at: git://github.com/geneC/syslinux.git pxechn-fix-news-for-hpa Gene Cumm (2): pxechn: Turn off debug NEWS: add pxechn.c32 NEWS | 3 +++ com32/modules/pxechn.c | 16

...transaction id elapsed.seconds secs Secs elapsed since client boot flags flags DHCP Flags field client.ip.addr ciaddr client IP addr your.ip.addr yiaddr 'Your' IP addr. (from server) server.ip.addr siaddr Boot server IP addr gateway.ip.addr giaddr Relay agent IP addr client.mac chaddr Client hardware addr server.hostname sname Optl. boot server hostname boot.file file boot file name (ascii path) magic.cookie co...

All, I realize this is not strictly a PXELINUX question. So I hope you'll indulge me; hopefully some of these PXELINUX experts have seen this before. And can tell me what I'm doing wrong. Or confirm my suspicions. I have a test lab server at work. Split config. The network team manages the DHCP servers, points to our TFTP server. Test subnet has 3 DHCP pools. BIOS PXE, UEFI PXE and

...his, I believe I have about everything implemented except I'm uncertain about the DHCP field giaddr (pxe_bootp_t.gip). My current test environment doesn't utilize this (just 0). I'm mostly looking to see if it's something that it might be desirable to modify. DHCP fields sname and siaddr are already adjusted as needed. -- -Gene

...> > As I suspected, exposed. Someone thought we should parse DHCP option > 54 for the next server to use which is completely wrong. A DHCP, > proxyDHCP or PXE server could point clients to other addresses but > always record their own IP in option 54. It should use BOOTP field > siaddr, resolve DHCP option 66 or resolve BOOTP field sname. Since we > only pay attention to siaddr for now, this is a minimal change to fix. This should help. -- -Gene diff --git a/core/fs/pxe/dhcp_option.c b/core/fs/pxe/dhcp_option.c index 8d93a6a..5cc0ef7 100644 --- a/core/fs/pxe/dhcp_option....

...) = 1 (Ethernet (10Mb)) DHCP: Hardware address length (hlen) = 6 octets DHCP: Relay agent hops = 0 DHCP: Transaction ID = 0x58c771d DHCP: Time since boot = 0 seconds DHCP: Flags = 0x0000 DHCP: Client address (ciaddr) = 0.0.0.0 DHCP: Your client address (yiaddr) = 0.0.0.0 DHCP: Next server address (siaddr) = 0.0.0.0 DHCP: Relay agent address (giaddr) = 0.0.0.0 DHCP: Client hardware address (chaddr) = 00:16:3E:1E:87:45 DHCP: DHCP: ----- (Options) field options ----- DHCP: DHCP: Message type = DHCPREQUEST DHCP: Requested IP Address = 192.168.2.111 DHCP: IP Address Lease Time = -1 seconds DHCP: Maximum...

...= 1 (Ethernet (10Mb)) DHCP: Hardware address length (hlen) = 6 octets DHCP: Relay agent hops = 0 DHCP: Transaction ID = 0xd6054229 DHCP: Time since boot = 12 seconds DHCP: Flags = 0x0000 DHCP: Client address (ciaddr) = 0.0.0.0 DHCP: Your client address (yiaddr) = 0.0.0.0 DHCP: Next server address (siaddr) = 0.0.0.0 DHCP: Relay agent address (giaddr) = 0.0.0.0 DHCP: Client hardware address (chaddr) = 00:16:3E:00:00:E4 DHCP: DHCP: ----- (Options) field options ----- DHCP: DHCP: Message type = DHCPDISCOVER DHCP: Maximum DHCP Message Size = 1472 bytes DHCP: IP Address Lease Time = -1 seconds DHCP: Clie...

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] BOOTP/DHCP, Reply, >> length 399, xid 0xf0eb955a, secs 14, Flags [none] (0x0000) >> Your-IP 10.141.20.2 >> Server-IP 10.141.255.254 >> Client-Ethernet-Address fa:16:3e:08:31:b9

...make it jump to a different tftp server from WDS? That's what I'm going for. I want the default PATH to include the IP address of a different TFTP server in PXE Linux. Certainly though the choices on how depend on BIOS versus EFI. If loaded properly from the second tftpd, this should set siaddr/sname to the second server. If you need to load the Syslinux binary from the first then use the second for the rest, you'll need option 210 (forced by DHCP or built-in options; no client normal would request this option from a DHCP). > The new implementation will have to have a separate fol...

On Wed, Oct 7, 2015 at 2:33 AM, Geert Stappers <stappers at stappers.nl> wrote: > On Tue, Oct 06, 2015 at 10:27:15PM -0400, Gene Cumm via Syslinux wrote: >> > On Fri, Oct 2, 2015 at 4:07 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> >> >> >> I have a patch that I think may help your situation of syslinux.efi >> >> being unable to load

Hey guys, We are going with WDS to fire up first to get the benefits of targeted M$ deployments. If you have the "handle unknown computers" off on your M$ Distribution point, then you can still use regular WDS which runs next as a PXE filter (DLL linked into WDS) to fire off anything you want to including PXELinux. The stuff I was talking about before with PXELinux not working in

...Some have also noticed wdsnbp.com doing something resembling another round of DHCP (discover/ack/request/offer). Working on pxechn.c32 I've found the "issue" and incorporated a workaround into pxechn.c32. wdsnbp.com issues a DHCP discover to the IP address listed in packet #2's siaddr field. This normally is set to the fist boot server if no full PXE response is received (in which case the boot server is in packet #3). When performing a PXE restart (as with pxechain.com), normally only packet #3 is altered. This results in wdsnbp.com asking the wrong server for information. p...