alternative dhcp server?

[AT-HE]

hi

anyone knows an alternative dhcp server for windows?

- has to be for windows nt/xp/vista/7 (workstation, not server)
- has to be free software or freeware
- must support ipxe chainloading without need to recompile ipxe

unfortunately i have no linux server at this time, only windows xp, maybe i can boot my netbook from my windows xp box

i had using tftpd32, very good program but it doesnt support chainloading .. ant it seems microsoft dhcp server cannot be installed no way on windows xp

[mcb30]

(2011-04-06 01:29)AT-HE Wrote:  i had using tftpd32, very good program but it doesnt support chainloading

Looking at the tftpd32 source code, it seems that it currently allows for expansion of $IP$ and $MAC$ tokens within the configured boot filename.

It wouldn't be more than a few hours of work to add support for expanding $USERCLASS$ (i.e. the DHCP http://ipxe.org/cfg/user-class option) as well. That would let you do something like:

• Configure boot filename in tftpd32 as "$USERCLASS$boot.pxe"
• Serve up http://boot.ipxe.org/undionly.kpxe as "boot.pxe"
• Serve up an iPXE script as "iPXEboot.pxe"
  

The first DHCP request would have no user-class, and so would receive "boot.pxe" (which would be a copy of undionly.kpxe). The second DHCP request would have a user-class of "iPXE", and so would receive "iPXEboot.pxe" (which would be your iPXE script).

Instant chainloading support!

[Sha0]

(2011-04-06 01:29)AT-HE Wrote:  anyone knows an alternative dhcp server for windows?

Alternative to what?

Included on Windows XP's installation disc is the TFTPD.EX_ file, which you can expand thusly:

Code:

expand d:\i386\tftpd.ex_ c:\windows\system32\tftpd.exe

You may then install this MS TFTP service with something like:

Code:

sc create TFTPD binPath= C:\Windows\System32\TFTPD.EXE depend= tcpip DisplayName= "TFTP Service"
net start tftpd

(Note the spaces are intentional and required.)

(2011-04-06 01:29)AT-HE Wrote:  - must support ipxe chainloading

A handy feature iPXE has is support for embedded scripts. An embedded script can then download another script, based on some client-specific parameters.

my_script.ipxe:

Code:

#!ipxe
dhcp net0
chain tftp://${next-server}/${ip}.ipxe

192.168.0.101.ipxe:

Code:

#!ipxe
echo Welcome, AT-HE!
...

To build this iPXE NBP payload:

Code:

cd ipxe/src/
make EMBEDDED_IMAGE=my_script.ipxe bin/ipxe.pxe

--- EDIT ---

I'm sorry, I misread "dhcp server" as "TFTP server". Never mind.

[AT-HE]

i want a -dhcp server- for windows (but thanks for the tip on tftp service) that supports $next-server or $userclass or whetever needed to avoid to recompile code

i know that by recompiling code i could use any dhcp server so this post didnt exists, but is not an option for me by now (and is not for many)


in relation to mcb30's response. it seems tftpd32 supports many features that aren't accessible through gui but by editing ini file .. anyone knows how to do it? .. or knows another dhcp server as asked in the first post?

thanks in advance

[mcb30]

(2011-04-06 14:06)AT-HE Wrote:  i want a -dhcp server- for windows (but thanks for the tip on tftp service)

Probably a dumb question, but can the Microsoft DHCP server be installed using the same method that Sha0 described for the Microsoft TFTP server?

[robinsmidsrod]

(2011-04-06 01:29)AT-HE Wrote:  anyone knows an alternative dhcp server for windows?

- has to be for windows nt/xp/vista/7 (workstation, not server)
- has to be free software or freeware
- must support ipxe chainloading without need to recompile ipxe

Have you tried this software? http://ruttkamp.gmxhome.de/dhcpsrv/dhcpsrv.htm

In the INI file reference it mentions UseClientID and VENDORCLASS options. Maybe you can configure those in a certain way so that they will allow chainloading undionly.kpxe in the right way?

[Sha0]

(2011-04-07 15:12)mcb30 Wrote:  ...can the Microsoft DHCP server be installed using the same method...described for the Microsoft TFTP server?

Actually... In my XP Pro installation source, I do see tcpsvcs.exe, which is the binary with the DHCPServer service on Windows Server 2003. However, I do not see DHCPSSVC.DLL, so that component would have to be licensed and available from another source. Too bad.

[AT-HE]

(2011-04-07 18:43)Sha0 Wrote:  

(2011-04-07 15:12)mcb30 Wrote:  ...can the Microsoft DHCP server be installed using the same method...described for the Microsoft TFTP server?

Actually... In my XP Pro installation source, I do see tcpsvcs.exe, which is the binary with the DHCPServer service on Windows Server 2003. However, I do not see DHCPSSVC.DLL, so that component would have to be licensed and available from another source. Too bad.

do you mean we have to copy DHCPSSVC.DLL from a win2k3?

can you try to install msdhcp on winxp and tell us how? .. i attached the file just grabbed from a win2k3 srv ent r2 eng

EDIT:

MCB30: please tell us somewhere what are the file types allowed to upload

[Sha0]

(2011-04-07 19:15)AT-HE Wrote:  do you mean we have to copy DHCPSSVC.DLL from a win2k3?

I did, indeed.

(2011-04-07 19:15)AT-HE Wrote:  can you try to install msdhcp on winxp and tell us how?

I quickly messed around with this idea and without success, but will try again after work.

(2011-04-07 19:15)AT-HE Wrote:  ...please tell us somewhere what are the file types allowed to upload

A "rules" posting is probably a good idea.

[mcb30]

(2011-04-07 19:15)AT-HE Wrote:  can you try to install msdhcp on winxp and tell us how? .. i attached the file just grabbed from a win2k3 srv ent r2 eng

EDIT:

MCB30: please tell us somewhere what are the file types allowed to upload

I haven't added any specific restrictions; it'll just be whatever the defaults are for MyBB.

That said; I'd prefer not to have any copyright-infringing files (e.g. portions of Windows) available for download from the iPXE forum, so I'm quite relieved that the upload was blocked. I'm pretty sure Sha0 has access to the Win2k3 server CDs, so you can just mention files by name rather than uploading copies of them.

[Z.C.]

Some freeware DHCP/TFTP alternatives include:

IPTools (made for gPXE and iSCSI)(for Windows):
http://erwan.l.free.fr/iscsi/

DNSMasq (lightweight DHCP/DNS/TFTP program)(for Linux)(designed for linux routers):
http://www.thekelleys.org.uk/dnsmasq/doc.html

[AT-HE]

thanks Z.C. but i was asking for a dhcp server for windows (xp, 7) that supports chainloading

i will ask myself

i am trying http://www.dhcpserver.de , it seems suports any option from dhcp, configurable via ini file

besides it supports tftp, dns and http (would support php and virtual hosts? )

anyone had used this program?? .. post your experience

[patpat]

As an alternative multi-server (including DHCP) you guys can give Serva32/64 a try…
http://www.vercot.com/~serva/

about chainloading:
1) I think the $USERCLASS$” is kind of an ugly hack, non portable to other DHCP servers, etc etc…
2) Dispatching different payloads for option 67 on different DHCP answers it represents also a problem; DHCP (v4) is a stateless protocol, and DHCP server engines (v4) are stateless, I do not consider changing the protocol engine to statefull would be a good approach.
3) Then why not answering the “file” field blank and both options 67 “in the same DHCP answer”?…
I think making ipxe able to chose option 67 #2, or #3 or #whatever should be very easy to do (from a programmers point of view), and also it would be completely portable..

Just my 2 cents
Pat

[AT-HE]

forgive my basic dhcp knowledge

do you mean chainloading feature would be -completely- compatible to ANY dhcp server??

that would be really nice! .. how? .. can you explain us with apples? .. can we tell to mcb30?

(2011-08-25 16:14)patpat Wrote:  As an alternative multi-server (including DHCP) you guys can give Serva32/64 a try…
http://www.vercot.com/~serva/

about chainloading:
1) I think the $USERCLASS$” is kind of an ugly hack, non portable to other DHCP servers, etc etc…
2) Dispatching different payloads for option 67 on different DHCP answers it represents also a problem; DHCP (v4) is a stateless protocol, and DHCP server engines (v4) are stateless, I do not consider changing the protocol engine to statefull would be a good approach.
3) Then why not answering the “file” field blank and both options 67 “in the same DHCP answer”?…
I think making ipxe able to chose option 67 #2, or #3 or #whatever should be very easy to do (from a programmers point of view), and also it would be completely portable..

Just my 2 cents
Pat

[mcb30]

(2011-08-25 16:14)patpat Wrote:  about chainloading:
1) I think the $USERCLASS$” is kind of an ugly hack, non portable to other DHCP servers, etc etc…

The primary constraint is the requirement to work out-of-the-box with the Microsoft DHCP server, which has very limited support for conditional responses. This DHCP server can vary the response based on the DHCP user class, and we can use an iPXE-specific user class without running afoul of any of the various specifications (DHCP, PXE, etc.).

ISC dhcpd is flexible enough to cope with pretty much any scheme; it's just simplest to document a scheme that works in exactly the same way for both ISC dhcpd and the Microsoft DHCP server.

Quote:2) Dispatching different payloads for option 67 on different DHCP answers it represents also a problem; DHCP (v4) is a stateless protocol, and DHCP server engines (v4) are stateless, I do not consider changing the protocol engine to statefull would be a good approach.

Using the DHCP user class to determine the response is still stateless. The response depends only upon the request. No state is retained by the server.

Quote:3) Then why not answering the “file” field blank and both options 67 “in the same DHCP answer”?…
I think making ipxe able to chose option 67 #2, or #3 or #whatever should be very easy to do (from a programmers point of view), and also it would be completely portable..

1. You won't be able to persuade most DHCP servers to specify multiple versions of option #67 in the same packet.
2. Even if you could do so, you'd be violating the DHCP standard by treating them as separate options. RFC3396 (and RFC2131) state that "when more than one option with a given type code appears in the DHCP packet, all such options should be concatenated together".
3. You would still need some way to specify which of the equivalent options was intended to be used.
   

Michael