search for: rfc2131

...4-03-05 at 13:18 -0500, Gene Cumm wrote: > Second, I notice the Altiris server specifies _3_ options of code 43, > including one of length 253. The pack/unpack _should_ handle this but > may split it differently. That's legal, and treated as if the values had been concatenated. See RFC2131, section 4.1, and particularly the second paragraph on page 24. Unfortunately, a lot of implementations get this wrong. For example, some client implementations cannot handle encapsulated vendor options that span more than once instance of the enclosing option 43. In this case, it appears that th...

...a proxyDHCP and attempting to grab the boot filename, BIOS specifies an incorrect sending/listening (source/destination) port pair. It should be 68/4011 but sends 4011/4011. I updated this for IPv4 but noticed that the problem has been carried over to IPv6 code in our code base. <<< RFC2131 says: "DHCP uses UDP as its transport protocol. DHCP messages from a client to a server are sent to the 'DHCP server' port (67), and DHCP messages from a server to a client are sent to the 'DHCP client' port (68)." but RFC2131 does not define a proxyDHCP serv...

Hi Gene, >> What I'm looking to do here is establish a bit of a convention for >> allowing machines of multiple architectures to be perform PXE >> configuration in a uniform way (in this case, without requiring the DHCP >> server to send out different lease parameters in response to the >> client's DHCP architecture ID). > > How do you have multiple

...t string is used for a file name in the TFTP request for the boot binaries (ie pxelinux.0 bootia32.efi bootx64.efi)?? How do you manipulate the DHCP offer to evoke this behavior (ie a BIOS machine receiving "pxelinux.0" in the DHCP/BOOTP field "file") http://tools.ietf.org/html/rfc2131 Figure 1 for field file. -- -Gene _______________________________________________ Syslinux mailing list Submissions to Syslinux at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic.

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

On Thu, 2014-03-06 at 16:52 -0500, Gene Cumm wrote: > > RFC2131, section 4.1, and particularly the second paragraph on page 24. > > Conditionally. "Options may appear only once, unless otherwise > specified in the options document." I don't see any indication of any > options that DO allow it unless "The information is an opaqu...

...tu/+archive/primary/+files/klibc_2.0.4-8ubuntu1.debian.tar.xz It would be nice if it is correctly fixed upstream. as this bug affects lot of distros. Basically the function dhcp_send() at dhcp_proto.c mistakenly define bootp.yiaddr = dev->ip_addr; when in a client originated DHCP DHCPREQUEST(RFC2131 Page 36) it should be bootp.yiaddr = INADDR_ANY; // "0" and also it forgets to define the flags bootp.flags = htons(0x800); Best, Patrick Signed-off-by: Patrick Masotta <masottaus at yahoo.com> --- diff -uprN a/klibc-2.0.4/usr/kinit/ipconfig/dhcp_proto.c b/klibc-2.0.4/usr/k...

....hlen = dev->hwlen; bootp.xid = dev->bootp.xid; bootp.ciaddr = INADDR_ANY; - bootp.yiaddr = dev->ip_addr; + /* yiaddr should always be set to 0 for the messages we're likely + * to send as a DHCP client: DHCPDISCOVER, DHCPREQUEST, DHCPDECLINE, + * DHCPINFORM, DHCPRELEASE + * cf. RFC2131 section 4.1.1, table 5. + */ + bootp.yiaddr = INADDR_ANY; bootp.giaddr = INADDR_ANY; + bootp.flags = htons(0x8000); bootp.secs = htons(time(NULL) - dev->open_time); memcpy(bootp.chaddr, dev->hwaddr, 16);

...> the giaddr field on dhcp_send in dhcp_proto.c, line 164. thank you for digging into it. > Otherwise, the relay agent SHALL forward any received DHCP packet > with a valid non-zero giaddr WITHOUT adding any relay agent options. > Per RFC 2131 < > ;http://www.faqs.org/rfcs /rfc2131.html>, it shall also NOT modify the > giaddr value. got also a single klibc Debian bug report on it: -> http://bugs.debian.org/432977 i'm adding the patch to my branch and will submit it to hpa asap. -- maks

...t string is used for a file name in the TFTP request for the boot binaries (ie pxelinux.0 bootia32.efi bootx64.efi)? How do you manipulate the DHCP offer to evoke this behavior (ie a BIOS machine receiving "pxelinux.0" in the DHCP/BOOTP field "file") http://tools.ietf.org/html/rfc2131 Figure 1 for field file. -- -Gene

...ile name in the TFTP request for the > boot binaries (ie pxelinux.0 bootia32.efi bootx64.efi)? How do you > manipulate the DHCP offer to evoke this behavior (ie a BIOS machine > receiving "pxelinux.0" in the DHCP/BOOTP field "file") > > http://tools.ietf.org/html/rfc2131 Figure 1 for field file.

..._should_ handle this but >> may split it differently. > > That's legal, and treated as if the values had been concatenated. See I never said that it was against the RFC. I was merely stating the level of functionality of the C functions pxechn.c32 uses might not cooperate. > RFC2131, section 4.1, and particularly the second paragraph on page 24. Conditionally. "Options may appear only once, unless otherwise specified in the options document." I don't see any indication of any options that DO allow it unless "The information is an opaque object of n octets...

...DHCP clients in default settings send by using Wireshark. 'p' means that padding is included. Dis. Req. Client 35 47 ipconfig(master of git) 64p 64p isc-dhclient(4.1.1-P1 in Debian-squeeze) 64p 73 WindowsXP 32bit(my x86 PC) 64p 76 WindowsVista 64bit(my amd64 PC) I referred to RFC2131, RFC1541 and RFC951 for the length of 'options' (called 'vend' in BOOTP) field of DHCP Discover and Request packet. Basing on RFC, if the length is ... 64 octets: BOOP server which may be able to interpret DHCP too and DHCP server which can interpret 'options' of variabl...

This is what I'm seeing on my DHCP server: # tcpdump -i eth0 -vvv -s 1500 '(port 67 or port 68)' tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes 13:24:05.679950 IP (tos 0x0, ttl? 20, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 00:24:54:d9:d4:2f (oui

Hi list, Does someone know a way to automatically store the hwaddress in the AD? I'm using Veyon in my school to manage the students PCs and if the hwadress is populated in the AD, the Room configuration can be set with AD otherwise i have to manage rooms manually. I'm using samba4 with bind and isc-dhcp-server are on the same server. Can we use scripts or some ways? thanks in advance

The following patches come from Debian and/or Ubuntu packages of klibc. Ben. Ben Hutchings (1): [klibc] run-init: Add dry-run mode Jay Vosburgh (1): [klibc] ipconfig: Use separate sockets for DHCP from multiple interfaces Mathieu Trudel-Lapierre (1): [klibc] ipconfig: Set broadcast when sending DHCPREQUEST and DHCPDISCOVER YunQiang Su (1): [klibc] mips: setjmp.S: don't

Hi all, Link protection is a new feature we are planning to introduce to Solaris and we would like to solicit your feedback on it. Please see attached document for details.

hi all... again... i sent this message to general questions but nobody got excited about it. i just installed 6 on my t30 laptop. brand new. when trying dhclient i get: DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 5 this trys 6 times then this shows up: No DHCPOFFERS received. No working leases in present database - sleeping. i run a tcpdump while requesting a lease and for