search

adeepv / staticdhcpd

Automatically exported from code.google.com/p/staticdhcpd
GNU General Public License v3.0
0 stars 0 forks source link

PXEboot not properly implemented #3

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
= From e-mail =

I am trying to use staticdhcpd (downloaded a few days ago) to support pxeboot.

Seems it is more than just add a few options related to booting (i.e., 
tftp_server_name, bootfile_name etc.) in dhcp._DHCPServer._loadDHCPPacket. As I 
got: PXE-E55: ProxyDHCP service did not reply to request on port 4011. 

To support pxeboot, we need both standard DHCP on port 67 and ProxyDHCP on port 
4011?

thanks,

Andrew

Original issue reported on code.google.com by red.hamsterx on 29 Dec 2010 at 4:46

GoogleCodeExporter commented 9 years ago 
Hi, Andrew.

It looks like you're right; I never noticed since I've never actually worked 
with PXE.

The documentation for the required extensions looks pretty clear, so I should 
have a prototype implemented this upcoming weekend. If you'd be able to help me 
test it, or give me some details about your setup so I can try to mirror your 
environment here, that would be very, very helpful.

Thanks for letting me know!

Original comment by red.hamsterx on 29 Dec 2010 at 4:48

GoogleCodeExporter commented 9 years ago 
hi Neil,

Thanks for getting back to me so quickly.

I set the options for tftp_server_name (66), bootfile_name (67) in 
dhcp._DHCPServer._loadDHCPPacket with hardcoding. The client is a virtual 
machine (vm) on VMware esxi hypervisor. The vm is on the same subnet as the 
staticdhcpd server. It sends Discover request which is picked up by staticdhcpd 
server. The server sends offer back to vm, vm then send Request. Then the 
server Acks. For some reason, the vm thinks the dhcpd server is a ProxyDHCP, 
and send in request on port 4011. See the screenshot attached.

Original comment by andrew.x...@gmail.com on 29 Dec 2010 at 9:44

GoogleCodeExporter commented 9 years ago 
forgot the screenshot

Original comment by andrew.x...@gmail.com on 29 Dec 2010 at 9:46

Attachments:

GoogleCodeExporter commented 9 years ago 
It looks like, from the protocol specs, I'll just need to make the code bind to 
4011 (if PXE support is turned on in the config file) and do a little special 
massaging if the request comes in on that port, but that should be the only 
change.

I can replicate this setup at work, so I should be able to test the 
implementation for stupid errors before involving you to do the real trials.

As for the changes you made to the code, see if you can put them into the 
loadDHCPPacket() function in conf.py. That gets called after all internal 
processing is done (logically, it happens immediately after the function you 
edited) and it's a cleaner way to add custom behaviour to the system. It's also 
more future-proof, since I won't be redefining that function, though I may, at 
some point, rewrite the section you've altered. Details on how to add custom 
behaviour is in the "rules" article of the wiki.

Original comment by red.hamsterx on 29 Dec 2010 at 9:53

GoogleCodeExporter commented 9 years ago 
Actually, there's something I'd like to know about your setup.

Your PXE server is not the same host as your DHCP server, right?

Original comment by red.hamsterx on 29 Dec 2010 at 10:06

GoogleCodeExporter commented 9 years ago 
Er... Ignore that last request for information. I was misunderstanding 
something.

http://blog.scalable.com/devrant/2010/02/12/what-is-a-proxy-dhcp-server/ seems 
to put the process into an easy-to-understand perspective.

I'm going to tentatively declare that the need for PXE is a "special case" and 
require that its setup goes into the function provided in conf.py, rather than 
a new database table. I'll compensate for this by including a configuration 
example in the wiki.

My implementation will be thus: I'll add a boolean 'pxe' argument to the 
loadDHCPPacket() function that can be used to let you add needed options (60, 
66, 67) when the receiving port is 4011, and I'll make my code skip insertion 
of lease options (IP and gateway and stuff) whenever 'pxe' is true, so that you 
won't have to manually cull anything.

Let me know if that makes sense. I'll begin implementing the changes (which 
should be pretty simple) on Friday, as mentioned before.

Original comment by red.hamsterx on 29 Dec 2010 at 10:21

GoogleCodeExporter commented 9 years ago 
Okay, sorry about not getting stuff done on Friday. I finally had an 
opportunity to rest and my body gave in to the craving, and thent he weekend 
was filled with New Years-y stuff.

I'll have an implementation in branches/dev ready to go in about an hour, 
though. Maybe less.

Original comment by red.hamsterx on 3 Jan 2011 at 5:44

GoogleCodeExporter commented 9 years ago 
Andrew, can you let me know exactly what you set in options 60, 66, and 67 so I 
can make appropriate changes to the mainline code?

Original comment by red.hamsterx on 3 Jan 2011 at 6:19

GoogleCodeExporter commented 9 years ago 
Though I'd still like to know what you set so I can be sure I'm understanding 
the specs right, branches/dev (1.5.2) should work for your needs.

A section on PXE was added to the FAQ and I exposed a logging feature for the 
user-accessible load function so you can easily track behavioural anomalies.

Please give it a try and let me know if it works. If you have to make any 
changes, please let me know what they are so I can update the code or 
documentation accordingly.

If you're running the system from SVN (recommended while troubleshooting 
issues/requesting new features), you can switch to the development branch with 
"svn switch http://staticdhcpd.googlecode.com/svn/branches/dev/ ." from the 
location where you checked out the trunk code (you can switch back to trunk 
once I've made these changes official).

If you're working from an archive, I recommend checking out the development 
branch and porting your SQL settings and conf.py changes over to help resolve 
this faster, since you can just type 'svn up' to pull the most recent changes 
when I have to revise something, but you can also grab the most recent static 
snapshot the same way I do to build the archives: "svn export 
http://staticdhcpd.googlecode.com/svn/branches/dev/ staticDHCPd-1.5.2-dev".

Thank you very much for your patience and help with addressing this problem.

Original comment by red.hamsterx on 3 Jan 2011 at 9:25

GoogleCodeExporter commented 9 years ago 
Neil,

Sorry for not monitoring the threads. I am not used to the googlecode's 
communication method yet. I will try the 1.5.2.

A comment on the FAQ:
 packet.setOption('bootfile_name', strToList(mac.replace(':', '').upper() + '.cfg'))

The bootfile name is usually something like 'pxelinux.0', it does not change 
with the machine that you booting with.

For 60: I set it to 'PXEClient', 66 set to the tftp server ip address, 67 set 
to the bootfile name '/tftpboot/pxelinux.0'

cheers,
Andrew

Original comment by andrew.x...@gmail.com on 5 Jan 2011 at 7:26

GoogleCodeExporter commented 9 years ago 
In my environment, the tftp server and pxe runs on the same machine. ISC's 
dhcpd implementation seem to use the same port (default 67) for DHCP and BOOTP.
Here is the Intel PXE spec 2.1., you might have already seen it.

Original comment by andrew.x...@gmail.com on 5 Jan 2011 at 7:32

Attachments:

GoogleCodeExporter commented 9 years ago 
The example I used was for a PBX system I set up recently. On it, the phones 
requested, via TFTP, a configuration file, rather than a boot image. I'm still 
not sure exactly what they did internally, but that's what I modeled it after. 
I will add your example if you think it might help make things clearer, though.

I didn't actually come across that document, but I'll get it a thorough review 
tonight and make any changes it suggests. Thanks for the link.

Original comment by red.hamsterx on 6 Jan 2011 at 12:06

GoogleCodeExporter commented 9 years ago 
PBX pxe boot, interesting.
I was able to boot up a host (suse vm on ESXi41) with the new code: 1.5.3. Will 
do more testing.

Original comment by andrew.x...@gmail.com on 6 Jan 2011 at 5:31

GoogleCodeExporter commented 9 years ago 
I'm going to consider this fixed, and I've rolled 1.5.3 into 1.5.4 and released 
it, but please re-open the issue if problems persist.

Original comment by red.hamsterx on 8 Jan 2011 at 9:17

GoogleCodeExporter commented 9 years ago 
I've been working on this for a bit, it appears that the server doesn't respond 
on port 4011. 

I dumped the following out with tcpdump:
14:18:41.841275 IP SRCIP.68 > SRVIP.4011: BOOTP/DHCP, Request from 
08:00:27:82:c9:ac, length 548
14:18:49.830508 IP SRCIP.68 > SRVIP.4011: BOOTP/DHCP, Request from 
08:00:27:82:c9:ac, length 548

It never responds, I'm using 1.5.5

What does work, is option 67. Option 66 seems to be ignored (which is what I 
need)

Original comment by sa...@appliedops.net on 17 Mar 2012 at 9:37