search for: rfc2132

Hi all, I'm trying to use a wrt54gl router running dd-wrt as a provisioning server for a remote installation. I've got dhcp working and I have provisioning files ready to go. I understand that I need to set bootp option 66 to point to the tftp/ftp/http server. In fact, I have this working completely with the ISC dhcp server The problem is that I don't know how to get

...head, but you never know. Anyways, I'm playing with the LinkSys WRT54G router now with OpenWRT installed. I'm trying to use dnsmasq to give the same parameters. In dnsmasq.conf I've added: "dhcp-option=66,10.5.5.1" But the Cisco phones are ignoring it. According to RFC2132, DHCP Option/Code 66 is the TFTP server name. But the Cisco 79xx phones I've tested are ignoring this. My question is this, does the Cisco 79xx IP Phones use a different DHCP Code (other than 66) to define its TFTP server? Also, does the Cisco 79xx honor DHCP Option 42, which defines th...

...er and domain option. It seems that only IP and the above options where transfered. I googled for a solution, but nothing, like I was the only one with this problem ( may be I am?). Finally I decide to forcibly make the PXE "eat" this parameters. I read the RFC ( http://www.faqs.org/rfcs/rfc2132.html ). I found the required options and changed the line to read: if exists dhcp-parameter-request-list { # Always send the PXELINUX options, we need to insist on # 1=net mask 3=routers 6=domain name server 15=local domain # name a...

First, I'd like to configure my system to forward ip, to act as a gateway for my network. I've always used a script during startup to do this: echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -o ${UPLINK} -j SNAT --to ${IP_NAT} This works fine, however I want this permanent so I don't have to run the script on startup. I have the firewall setup with SNAT

On Wed, 2014-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

...appears in the DHCP vendor class identifier option. In this case, that's "PXEClient", which means the format of option 43 is defined in the PXE specification. The PXE specification is unfortunately rather vague, but does specify the use of encapsulated vendor options, refers once to RFC2132, and does not define any different encapsulation format. In any case, I think I was barking up the wrong tree. What the trace shows is a normal DHCP handshake with the server at 10.215.144.7, along with the Altiris server responding in so-called "Proxy DHCP" mode, in which it provides...

...Both for PXE boots and for EFI boots. I've noticed this IBA quirk for years. According to the "DHCP options" RFC, variable length DHCP options are not necessarily null-terminated. Here's the details: >From DHCP Options and BOOTP Vendor Extensions (http://tools.ietf.org/html/rfc2132#section-2) BOOTP Extension/DHCP Option Field Format DHCP options have the same format as the BOOTP 'vendor extensions' defined in RFC 1497 [2]. Options may be fixed length or variable length. All options begin with a tag octet, which uniquely identifies the option. Fixed-length options wi...