Re: [Dnsmasq-discuss] using gPXE in chainloader mode
> > > Due to holiday time constraints the server is now a production server, > and I wont be able to do more testing on this idea for awhile, I saved > my wireshark logs and I can enable gPXE in my "testing" pxemenu > options list. > > The gpxe people are going to be coding a workaround for the extra > space as there are a host of devices that requre the space, and > windows dhcp server includes the space as well. Good, I think that's the best solution. > > Thanks for the hint about the different ways to specify the optinos, > but Im happy with the production product now, and I will be testing > this again when the gPXE people get the workaround figured out. > > its easier for the gPXE people to get it fixed than it is to change > half the devices connected to the net. > > > Simon: I saved my wireshark logs, and can export them to you, I'm not > going to be able to test this further till the gPXE people get their > workaround fixed. > > Will touch base with you then, I hope this doesnt screw with the > schedule for the next version of dnsmasq, but thats the best I can do > for now. No problem. I'm confident that we understand the problem and solution for the zero-term problem. I'm also happy that an extra dnsmasq function is needed to use gPXE and I can add that to the next release. Thanks for you testing and input. Cheers, Simon. > > Merry Christmas all. > > > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >
Re: [Dnsmasq-discuss] using gPXE in chainloader mode
Quoting Carlos Carvalho : ra...@frontiernet.net (ra...@frontiernet.net) wrote on 23 December 2007 01:19: >I'm not sure if its a bug in dnsmasq or not, as I don't know the RFCs >well enough to make a judgement. But the gPXE people seemed convinced >that dnsmasq was somehow "wrong" in this. As Simon said, dnsmasq is just trying to cope with buggy clients. Your machines cannot handle a terminating null in the filename but my machines (pxe rom in Asus motherboards) don't work without it... You can try to pass options 66 and 67 as dhcp-option directives instead of dhcp-boot; these don't include a null byte at the end of filenames. Besides, this way you can put the directives in a dhcp-optsfile which is re-read with a HUP, instead of having to restart dnsmasq. You need version test25 for this. Due to holiday time constraints the server is now a production server, and I wont be able to do more testing on this idea for awhile, I saved my wireshark logs and I can enable gPXE in my "testing" pxemenu options list. The gpxe people are going to be coding a workaround for the extra space as there are a host of devices that requre the space, and windows dhcp server includes the space as well. Thanks for the hint about the different ways to specify the optinos, but Im happy with the production product now, and I will be testing this again when the gPXE people get the workaround figured out. its easier for the gPXE people to get it fixed than it is to change half the devices connected to the net. Simon: I saved my wireshark logs, and can export them to you, I'm not going to be able to test this further till the gPXE people get their workaround fixed. Will touch base with you then, I hope this doesnt screw with the schedule for the next version of dnsmasq, but thats the best I can do for now. Merry Christmas all.
Re: [Dnsmasq-discuss] using gPXE in chainloader mode
ra...@frontiernet.net (ra...@frontiernet.net) wrote on 23 December 2007 01:19: >I'm not sure if its a bug in dnsmasq or not, as I don't know the RFCs >well enough to make a judgement. But the gPXE people seemed convinced >that dnsmasq was somehow "wrong" in this. As Simon said, dnsmasq is just trying to cope with buggy clients. Your machines cannot handle a terminating null in the filename but my machines (pxe rom in Asus motherboards) don't work without it... You can try to pass options 66 and 67 as dhcp-option directives instead of dhcp-boot; these don't include a null byte at the end of filenames. Besides, this way you can put the directives in a dhcp-optsfile which is re-read with a HUP, instead of having to restart dnsmasq. You need version test25 for this.
Re: [Dnsmasq-discuss] using gPXE in chainloader mode
ra...@frontiernet.net wrote: Ive puged all the history in the interest of brevity: This should be my final post on using gPXE with dnsmasq First, the gPXE peop[e claim that there is a bug in dnsmasq that appends an extra chaaracter hex(00) at the end of all dhcp supplied option values. a snooped dhcpoffer packet with wireshark confirms the asserstion by the gPXE people. The fact is that a 13 character bootfile name is a legth 14 option in the dhcpoffer packet I'm not sure if its a bug in dnsmasq or not, as I don't know the RFCs well enough to make a judgement. But the gPXE people seemed convinced that dnsmasq was somehow "wrong" in this. Ignore my previous post: the "microsoft detector" is irrelevant here; this comment from the code tells all. /* See if we can send the boot stuff as options. To do this we need a requested option list, BOOTP and very old DHCP clients won't have this, we also provide an manual option to disable it. Some PXE ROMs have bugs (surprise!) and need zero-terminated names, so we always send those. */ I think I still own the PXE ROM which demonstrates the bug. This indicates a possible workaround: use --dhcp-no-override which stops dnsmasq from putting the filename is an option and always leaves it in the dedicated filename field, where termination is not an issue. I'm confused about the bootfilename with a space at the end. They're using space as an end marker? Note that if you want a space at the end of your filename, you'll probably have to use quotes. dhcp-boot="somename " The two DHCPdiscover packets you send are indistuishable in any released version of dnsmasq. I'll add a facility to do it and get it to you ASAP, holidays permitting. Cheers, Simon.
Re: [Dnsmasq-discuss] using gPXE in chainloader mode
ra...@frontiernet.net wrote: Ive puged all the history in the interest of brevity: This should be my final post on using gPXE with dnsmasq First, the gPXE peop[e claim that there is a bug in dnsmasq that appends an extra chaaracter hex(00) at the end of all dhcp supplied option values. a snooped dhcpoffer packet with wireshark confirms the asserstion by the gPXE people. The fact is that a 13 character bootfile name is a legth 14 option in the dhcpoffer packet I'm not sure if its a bug in dnsmasq or not, as I don't know the RFCs well enough to make a judgement. But the gPXE people seemed convinced that dnsmasq was somehow "wrong" in this. I'm a bit short of time to do a complete analysis at the moment, I'll get back to you later with that. It worth knowing that dnsmasq is supposed to detect buggy microsoft zero-terminated options, and only send back zero-terminated options only when it sees them. ie if the hostname sent by the client is zero-terminated, then all string options returned by dnsmasq will also be zero terminated, otherwise they won't be. RFC-compliance is definately NOT zero-terminated, but that will break eg the Windows 98 DHCP client. It's possible that this code is being confused, or is too simple-minded, I'm off to stick pins in my effigy of Bill Gates now.. Cheers, Simon.
Re: [Dnsmasq-discuss] using gPXE in chainloader mode
Ive puged all the history in the interest of brevity: This should be my final post on using gPXE with dnsmasq First, the gPXE peop[e claim that there is a bug in dnsmasq that appends an extra chaaracter hex(00) at the end of all dhcp supplied option values. a snooped dhcpoffer packet with wireshark confirms the asserstion by the gPXE people. The fact is that a 13 character bootfile name is a legth 14 option in the dhcpoffer packet I'm not sure if its a bug in dnsmasq or not, as I don't know the RFCs well enough to make a judgement. But the gPXE people seemed convinced that dnsmasq was somehow "wrong" in this. Windowd dhcp server does this as well, but apparently isc-dhcpd does not. The gPXE people said that they would have to adjust for it as there was no way they could get windows to change their dhcpd program. basically gPCXE was looking for a bootfile with a space at the end of its name, and not finding it, and stopping there. Once gPXE can account for the extra data, or dnsmasq removes it, then the problem that I originally wrote about will be present. So I have been warned. I have two snooped dhcp discover packets capaured by wireshark. the first is the one that the pxebios got when the vmware virtual test machine booted. And the second one is when gPXE booted and asked for an ip address again. No. TimeSourceDestination Protocol Info 217 12.056662 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x2a040896 Frame 217 (590 bytes on wire, 590 bytes captured) Ethernet II, Src: Vmware_04:08:96 (00:0c:29:04:08:96), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255) User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67) Bootstrap Protocol Message type: Boot Request (1) Hardware type: Ethernet Hardware address length: 6 Hops: 0 Transaction ID: 0x2a040896 Seconds elapsed: 4 Bootp flags: 0x8000 (Broadcast) Client IP address: 0.0.0.0 (0.0.0.0) Your (client) IP address: 0.0.0.0 (0.0.0.0) Next server IP address: 0.0.0.0 (0.0.0.0) Relay agent IP address: 0.0.0.0 (0.0.0.0) Client MAC address: Vmware_04:08:96 (00:0c:29:04:08:96) Server host name not given Boot file name not given Magic cookie: (OK) Option: (t=53,l=1) DHCP Message Type = DHCP Discover Option: (53) DHCP Message Type Length: 1 Value: 01 Option: (t=55,l=24) Parameter Request List Option: (55) Parameter Request List Length: 24 Value: 01020305060B0C0D0F1011122B363C438081828384858687 1 = Subnet Mask 2 = Time Offset 3 = Router 5 = Name Server 6 = Domain Name Server 11 = Resource Location Server 12 = Host Name 13 = Boot File Size 15 = Domain Name 16 = Swap Server 17 = Root Path 18 = Extensions Path 43 = Vendor-Specific Information 54 = Server Identifier 60 = Vendor class identifier 67 = Bootfile name 128 = Private 129 = Private 130 = Private 131 = Private 132 = Private 133 = Private 134 = Private 135 = Private Option: (t=57,l=2) Maximum DHCP Message Size = 1260 Option: (57) Maximum DHCP Message Size Length: 2 Value: 04EC Option: (t=97,l=17) UUID/GUID-based Client Identifier Option: (97) UUID/GUID-based Client Identifier Length: 17 Value: 00564D2446242F648585B19F177C040896 Client Identifier (UUID): 46244d56-2f24-8564-85b1-9f177c040896 Option: (t=93,l=2) Client System Architecture = IA x86 PC Option: (93) Client System Architecture Length: 2 Value: Option: (t=94,l=3) Client Network Device Interface Option: (94) Client Network Device Interface Length: 3 Value: 010201 Client Network ID Major Version: 2 Client Network ID Minor Version: 1 Option: (t=60,l=32) Vendor class identifier = "PXEClient:Arch:0:UNDI:002001" Option: (60) Vendor class identifier Length: 32 Value: 505845436C69656E743A417263683A30303030303A554E44... End Option Padding and the second one that was gPXE requesting No. TimeSourceDestination Protocol Info 395 16.242627 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x29040896 Frame 395 (412 bytes on wire, 412 bytes captured) Ethernet II, Src: Vmware_04:08:96 (00:0c:29:04:08:96), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255) User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67) Bootstrap Protocol Message type: Boot Request (1) Hardware type: Ethernet Hardware address len
Re: [Dnsmasq-discuss] using gPXE in chainloader mode
sorry about the duplicate post, not sure what happened
Re: [Dnsmasq-discuss] using gPXE in chainloader mode
Quoting Simon Kelley :
ra...@frontiernet.net wrote:
First my reference url is http://www.etherboot.org/wiki/pxechaining
Seems the guys at etherboot have created gPXE, Im sure that this is old
news to many of you on this list, but it was news to me.
Im using dnsmasq and its built in tftp server and everything Ive tried
to do with dnsmasq has worked first time. (Read: Great Job Simon!)
Now I have a question about how to integrate gPXE into my dnsmasq setup.
When the chainloaded gPXE starts up, it will issue a fresh DHCP request
and boot whatever the DHCP server hands out. The DHCP server is
currently set up to hand out the gPXE image, which means that you will
be stuck in an infinite loop: PXE will load gPXE which will load gPXE
which will load gPXE which will load gPXE...
The easiest way to break this cycle is to configure the DHCP server to
hand out gPXE only for the first DHCP request. Using ISC DHCPD, you can
edit /etc/dhcpd.conf to contain:
option space gpxe;
option gpxe-encap-opts code 175 = encapsulate gpxe;
option gpxe.bus-id code 177 = string;
if not exists gpxe.bus-id {
filename "undionly.kpxe";
}
I can't find any documentation as to if this is possible with dnsmasq, I
searched the list archives for pxe boot problems but I didnt find
anything related to my question.
I don't recall seeing any logic around the decision of WHICH filename
option to send to pxebooted clients.
Any Ideas?
You can control which filename is sent using tags.
dhcp-boot=net:,
but that knowledge only transforms the problem into getting a tag set
for the initial PXE, but not the gPXE request, or vice-versa.
The procedure suggested for dhcpd isn't possible for dnsmasq; you can't
set a tag based on the presence or otherwise of an arbitrary option in
the DHCP request.
You can match in the contents of the vendorclass option, using
--dhcp-vendorclass. That might work, but a quick check of the code seems
to show gPXE sending a very familiar string as its vendorclass, so it
may well be impossible to tell the two requests apart that way.
The best we to check is to use wireshark to grab the DHCP requests, and
look for the contents of the vendorclass option in each one (option
number 60). If they're different, devise a match string for
--dhcp-vendorclass which matches one and not the other. If that's not
possible, come back here and I'll look at adding the required facility.
On a related note: people doing PXE should look at the dhcp-option-force
directive, that's needed to get options to whatever a PXE server chain
loads. The PXE code doesn't know what options the chain loaded code may
want, so it can't request them. Using dhcp-option-force you can send
those options anyway. This is essential to get options to PXELinux, for
instance.
Cheers,
Simon.
I just got done testing gPXE with two different setups:
1) as a menu option in my already working pxe menu
2) as a dhcp-boot replacement for pxelinux.0
there is no package for gPXE you can ony "git" the source with the
cvs/svn like "git" suite
as of todays sync download and compile, the referenced behavior did not occur.
im using dnsmasq 2.40 on centos 5.1 (via the rpmforge package set)
wireshark shows that the bootfile is sent correctly and gPXE is
ignoring the bootfile when it should
I didnt spend too much time witg gPXE once I got it working the way I
want to use it (as a boot menu option from my existing pxemenu)
I'm going to send a message to the etherboot discusstion list and see
if I can confirm that its a fixed bug and not a fluke.
Rance
Re: [Dnsmasq-discuss] using gPXE in chainloader mode
Quoting Simon Kelley :
ra...@frontiernet.net wrote:
First my reference url is http://www.etherboot.org/wiki/pxechaining
Seems the guys at etherboot have created gPXE, Im sure that this is old
news to many of you on this list, but it was news to me.
Im using dnsmasq and its built in tftp server and everything Ive tried
to do with dnsmasq has worked first time. (Read: Great Job Simon!)
Now I have a question about how to integrate gPXE into my dnsmasq setup.
When the chainloaded gPXE starts up, it will issue a fresh DHCP request
and boot whatever the DHCP server hands out. The DHCP server is
currently set up to hand out the gPXE image, which means that you will
be stuck in an infinite loop: PXE will load gPXE which will load gPXE
which will load gPXE which will load gPXE...
The easiest way to break this cycle is to configure the DHCP server to
hand out gPXE only for the first DHCP request. Using ISC DHCPD, you can
edit /etc/dhcpd.conf to contain:
option space gpxe;
option gpxe-encap-opts code 175 = encapsulate gpxe;
option gpxe.bus-id code 177 = string;
if not exists gpxe.bus-id {
filename "undionly.kpxe";
}
I can't find any documentation as to if this is possible with dnsmasq, I
searched the list archives for pxe boot problems but I didnt find
anything related to my question.
I don't recall seeing any logic around the decision of WHICH filename
option to send to pxebooted clients.
Any Ideas?
You can control which filename is sent using tags.
dhcp-boot=net:,
but that knowledge only transforms the problem into getting a tag set
for the initial PXE, but not the gPXE request, or vice-versa.
The procedure suggested for dhcpd isn't possible for dnsmasq; you can't
set a tag based on the presence or otherwise of an arbitrary option in
the DHCP request.
You can match in the contents of the vendorclass option, using
--dhcp-vendorclass. That might work, but a quick check of the code seems
to show gPXE sending a very familiar string as its vendorclass, so it
may well be impossible to tell the two requests apart that way.
The best we to check is to use wireshark to grab the DHCP requests, and
look for the contents of the vendorclass option in each one (option
number 60). If they're different, devise a match string for
--dhcp-vendorclass which matches one and not the other. If that's not
possible, come back here and I'll look at adding the required facility.
On a related note: people doing PXE should look at the dhcp-option-force
directive, that's needed to get options to whatever a PXE server chain
loads. The PXE code doesn't know what options the chain loaded code may
want, so it can't request them. Using dhcp-option-force you can send
those options anyway. This is essential to get options to PXELinux, for
instance.
Cheers,
Simon.
This message is to summarize for the list the results of my testing
configuration details:
netboot server os centos 5.1
dnsmasq version 2.40 installed as a package from the prmforge collection
gPXE compiled from source using fresh source sync using "git" on 12/21/07
ive set this up two different ways
I have made no changed to the dnsmasq setup at this point, I want to
see where my current status is.
First, as I have an extensive pxeboot menu setup including opitons for
netbooting the installers of several linux distros i adding to the
menu and fed a kernel command to the pxeclient.menu option and pxe
downloads gpxe and boots that. gpxe does optain a fresh dhcp address
but seems to ignore the boot instructions.
Looks like they have setup gpxe to parse the dchp response (which
includes the filename) and selectively not boot it, line perhaps if
the bootfile in the request is selectively ignored.
Ok, so I made a change to dnsmsq.conf to change the boot file name
that is being used.
Re: [Dnsmasq-discuss] using gPXE in chainloader mode
ra...@frontiernet.net wrote:
> First my reference url is http://www.etherboot.org/wiki/pxechaining
>
> Seems the guys at etherboot have created gPXE, Im sure that this is old
> news to many of you on this list, but it was news to me.
>
> Im using dnsmasq and its built in tftp server and everything Ive tried
> to do with dnsmasq has worked first time. (Read: Great Job Simon!)
>
> Now I have a question about how to integrate gPXE into my dnsmasq setup.
>
>
> When the chainloaded gPXE starts up, it will issue a fresh DHCP request
> and boot whatever the DHCP server hands out. The DHCP server is
> currently set up to hand out the gPXE image, which means that you will
> be stuck in an infinite loop: PXE will load gPXE which will load gPXE
> which will load gPXE which will load gPXE...
>
> The easiest way to break this cycle is to configure the DHCP server to
> hand out gPXE only for the first DHCP request. Using ISC DHCPD, you can
> edit /etc/dhcpd.conf to contain:
>
> option space gpxe;
> option gpxe-encap-opts code 175 = encapsulate gpxe;
> option gpxe.bus-id code 177 = string;
>
> if not exists gpxe.bus-id {
> filename "undionly.kpxe";
> }
>
>
>
> I can't find any documentation as to if this is possible with dnsmasq, I
> searched the list archives for pxe boot problems but I didnt find
> anything related to my question.
>
> I don't recall seeing any logic around the decision of WHICH filename
> option to send to pxebooted clients.
>
> Any Ideas?
>
You can control which filename is sent using tags.
dhcp-boot=net:,
but that knowledge only transforms the problem into getting a tag set
for the initial PXE, but not the gPXE request, or vice-versa.
The procedure suggested for dhcpd isn't possible for dnsmasq; you can't
set a tag based on the presence or otherwise of an arbitrary option in
the DHCP request.
You can match in the contents of the vendorclass option, using
--dhcp-vendorclass. That might work, but a quick check of the code seems
to show gPXE sending a very familiar string as its vendorclass, so it
may well be impossible to tell the two requests apart that way.
The best we to check is to use wireshark to grab the DHCP requests, and
look for the contents of the vendorclass option in each one (option
number 60). If they're different, devise a match string for
--dhcp-vendorclass which matches one and not the other. If that's not
possible, come back here and I'll look at adding the required facility.
On a related note: people doing PXE should look at the dhcp-option-force
directive, that's needed to get options to whatever a PXE server chain
loads. The PXE code doesn't know what options the chain loaded code may
want, so it can't request them. Using dhcp-option-force you can send
those options anyway. This is essential to get options to PXELinux, for
instance.
Cheers,
Simon.
