PXE booting WinPE fails

[GoogleCodeExporter]

What steps will reproduce the problem?
1. PXE booting a client to WinPE image
2.
3.

What is the expected output? What do you see instead?

The client was able to obtain bootfile and configuration file on PXE server. 
But when it tried to download the WinPE binary via tftp, it fails with the 
message:
    'TFTP download failed
  Press any key to reboot.'

The same setup worked for ISC dhcpd (V3.0.1). For detailed information from 
/var/log/messages file, please see attached file. I have listed the different 
response sequence under ISC and staticdhcpd.

What version of the product are you using? On what operating system?

staticdhcpd 1.5.3
pxe redhat el4u2
pxelinux 3.72
tftpd 0.39-3

Please provide any additional information below.

The client's pxe config file is:

default 1
timeout 1
prompt 1
label 1
kernel Boot/pxeboot.0
append -

/etc/default/tftpd.rules is as follows:

#Required for WinPE PXE support
rg \\boot.ini /boot.ini
rg \\Boot\\BCD /Boot/BCD
rg \\Boot\\boot.sdi /Boot/boot.sdi
rg \\Boot\\BOOT.WIM /Boot/BOOT.WIM
rg \\Boot\\Fonts\\wgl4_boot.ttf /Boot/Fonts/wgl4_boot.ttf
rg \\hiberfil.sys /hiberfil.sys 

Original issue reported on code.google.com by andrew.x...@gmail.com on 28 Jan 2011 at 11:44

Attachments:

• staticdhcpd_issue8.txt

[GoogleCodeExporter]

Can you provide a packet-dump (decoded preferred) using Wireshark (capture with 
filter "udp.port==67 or udp.port==68" -> stop -> print single packet to file as 
decoded ASCII) or tcpdump (tcpdump -i eth0 -s 1024 -vvv udp port 67 or port 68) 
showing both servers' responses?

I'm suspecting that ISC's server is sending a different siaddr value, but need 
to see the packets to substantiate (and help you address) that suspicion. We 
might find out something else of interest, too.

Original comment by red.hamsterx on 29 Jan 2011 at 8:54

• Changed state: Accepted

[GoogleCodeExporter]

some update on this.
Had some finding:
1)DHCP_FIELDS (siaddr and file) are not set through staticdhcpd. But the ISC's 
server set those values.
2)It was not correct to set file with just 
setOptions('file',strToList('pxelinux.0'))
because it expects a list of 128 bytes.

After setting the two values, I still can't boot. But this time, got a 
different error message: PXE-E32 TFTP open timeout

Seems it can now find the tftp server, but still can't connect.

Original comment by andrew.x...@gmail.com on 3 Feb 2011 at 8:08

[GoogleCodeExporter]

another update
I am so happy ...
It works now, I can see the tftp downloading winpe booting files.
It turned out I missed one digit in the conf.py when specifying tftpservier id

Original comment by andrew.x...@gmail.com on 3 Feb 2011 at 10:23

[GoogleCodeExporter]

Neil,

- Per this issue, I added a new method strToPaddedList(string,dhcp_field_length)
to src/libpydhcpserver/type_rfc.py.
- Also added a webservice connection method to lookup the IP.
- In dhcp_packet.py, added exception handling to:
   self._options_data[DHCP_OPTIONS_REVERSE[opt_id]] = opt_val 
  as I saw some incoming packets triggered unhandled exception here

For details please see the patch file.

Original comment by andrew.x...@gmail.com on 7 Feb 2011 at 10:20

[GoogleCodeExporter]

-

Original comment by andrew.x...@gmail.com on 7 Feb 2011 at 10:20

Attachments:

• axuan.txt

[GoogleCodeExporter]

Hi, Andrew. Sorry I haven't been responding: I was without Internet access from 
home as part of a protest against Canada's Usage-Based Billing thing and work 
was crazy-busy.

I'll incorporate your patch (thank you very much for taking the time to submit 
it and for adhering to the project's coding conventions!), minus the parts that 
modify loadDHCPPacket(), since they're obviously specific to your site's 
implementation.

Can you explain what the Webserves data-source is? It's the first time I've 
heard of such a thing and I'd like to know how to document it for other users.

Original comment by red.hamsterx on 14 Feb 2011 at 11:51

[GoogleCodeExporter]

Thanks for getting back to me.
The webservice source is Oracle database. I am doing this because I don't want 
to expose the database connection information and deal with tnsnames lookup etc.
So it is basically a https call to pass in 'action,mac,format' and get lookup 
result returned in the format specifed. So all the data retrieving logic is on 
the webservice host side. 

I am not quite sure about the performance yet. It would be slower than a direct 
database lookup.

Original comment by andrew.x...@gmail.com on 15 Feb 2011 at 10:09

[GoogleCodeExporter]

I've finally added everything from your patch to the dev branch, Andrew, except 
for the webservice thing, since that seems like it's pretty local to your site, 
and I'm *really* sorry it took so long. I could come up with a myriad of 
excuses, but they wouldn't be sufficient.

If you'd like, though, I can grant you committer access, since it seems like 
you know what you're doing, and while I expect to be more available during the 
summer, I can't guarantee anything.

Original comment by red.hamsterx on 23 Jun 2011 at 12:21

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for fixing the issue. And glad you finally get some free time.
Sure, I will be happy to get a committer access.

Andrew

Original comment by andrew.x...@gmail.com on 24 Jun 2011 at 2:19

[GoogleCodeExporter]

If you can e-mail me (red.hamsterx {at[ gmail or flan ]at} uguu.ca) the address 
of the Google Account you'd like to use to contribute to this project, I'll get 
that set up immediately, and then I'll send you a roadmap of what I have 
planned for the next little while. I'll also explain anything you might be 
unfamiliar with, small-team-source-control-system-wise.

In case I get swamped again, I'd like to know that the project will be under 
the control of someone who can prevent necessary bugfixes from sitting in limbo 
for months.

Original comment by red.hamsterx on 24 Jun 2011 at 5:16