1

I am following instructions from this link:
http://www.cyberstreams.com/install-windows-7-network-using-pxe-booting-tftp/
I have followed till step 8. However i am not getting past from that step. I am getting no cmd Window in client machine (client doesn't boot up at all). Client does gets an ip though. Tftpd says transferring files but is stuck at 0% and then timeout occurs.
For dhcp, I am using these settings:

IP pool starting address: 192.168.1.100
Size of pool: 10
WINS/DNS Server: 255.255.255.255
Default Router: 192.168.3.100
Mask: 255.255.255.0
Domain Name: empty
Additional Option: empty

I have tried newer version of tftpd but same result is coming.

Apologies if these settings are awfully messed up. I am doing this stuff for first time. Since I am trying this for educational purpose only, there's no stringent requirements for ip pool start or any such other values. In short, I can try any other value suggested...

  • Does your client get an IP in the 192.168.1.100-109 range? If not, it's grabbing the IP from another DHCP server (like your router). And is the firewall on your server allowing tftp? – Brandon Xavier Sep 5 '15 at 22:49
  • Yes, client is getting IP in that range. I am using Windows as host, so when I run tftpd32 first time, the windows firewall did pop up. I have allowed it for private as well as public network. Is there any more firewall thing to be done? – ashu Sep 6 '15 at 3:34
  • OK, I was avoiding asking this, but are you sure 192.168.1.100-109 is a valid range for YOUR network? What is your server's IP? Are any other devices on your network using addresses in that range? Have you noticed the default gateway (router) in your DHCP is NOT in the 192.168.1.0/24 network (probably not relevant IF everything is on 192.168.1.0/24)? One of your comments below (enabling the "ping before giving . . .") suggests you might have overlapping DHCP ranges or statically assigned IP addresses in your DHCP range. – Brandon Xavier Sep 6 '15 at 13:08
  • I am using direct one on one connection (server directly connected to client via LAN. Since I am doing for learning purposes I dont have many systems. I have also tried virtualbox for same and choosing network as internal network instead of NAT). Server's IP is 192.168.3.100 and other devices are also in 192.168.3.x so 192.168.1.x can't interfere with any existing devices. I dont know what values to fix in for different IP's, so I plugged values from one of the article in internet. If I found that article again, I will post it... – ashu Sep 6 '15 at 18:04
  • There's your problem. In this setup you need the client and server to be on the same IP subnet. As it is now, not only will they not interfere, they won't be able to communicate ;) Try making a tiny range DNS range in the 192.168.3.0/24 subnet . . . for example: 192.168.3.230-232 (Note: I would only recommend this for a simple one-off project like this - if you wanted this dhcp server running permanently you'd carve a range out of your main dhcp server to use for this - but for a one-off it's not worth the trouble) – Brandon Xavier Sep 6 '15 at 19:01
0

You are taking instruction from the typical cryptic PXE "how-to" that doesn't explain much. You could achieve your goal in a simpler manner by using Serva (I'm related to Serva development)

  • I tried serva now. Used same pxeboot.com file that I got from guide link though. According to syslog, client is unable to get IP (suppress ping address), but when I uncheck ping before giving ip option in dhcp, client gets ip in that range. After that, the problem that comes is same. It says in tftp server that its transferring files but its not actually able to do it. So, TFTP timeout occurs at client. – ashu Sep 6 '15 at 4:03
  • 1) if you use Serva you do not have to use your pxeboot.com. Also you do not have to check the DHCP option for pinging the IP before offering it. If I were you I'd stick to Serva Application Note. 2) There's a chance your client PXE firmware might be superseded by some new version; you should check that out before trying again. – Pat Sep 6 '15 at 8:00
  • Thanks for the help. While tftpd32/64 is now working, I will soon test Serva too to see which fits my scenario better in terms of performance... If I dont use pxeboot.com, then what will be the boot file to choose? I don't think Windows will simply boot to client by just specifying Windows directory. I am sorry but I am unable to understand "I'd stick to Serva Application"... – ashu Sep 7 '15 at 18:34
  • 1) "I'd stick to Serva Application" = "I would keep using Serva". 2) when you use Serva, Serva takes care of the NBP (Network Boot Program) and the chain of booting components "automatically". Just take the time and read the quoted Application Note. – Pat Sep 8 '15 at 15:07
  • Sure, this weekend will be Serva dedicated now. Thanks for your advice over Serva. Meanwhile, does Serva support command line parameters for its functionality. I am planning to implement same in my college, but their main system will be having Windows Server (hopefully gui less). I guess Windows Server has its own tftp service but officials aren't pleased with tampering/modifying with any Windows server service for time being and are open to external application to manage all kind of such stuff. – ashu Sep 9 '15 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.