TFTP Issues
-
I have a functioning fog server and it has been working well but I am seeing some issues. We have 2 buildings connected with fiber and the clients on the subnets are set to PXE boot first in the order. These all work with no problems.
However we have many other buildings that are connected via a VPN tunnel back to our main location. Whenever I attempt to PXEboot a client at any of these locations the box gets stuck at TFTP and never goes anywhere. When I issue the following command from any of the problem boxes the command is successful.
tftp x.x.x.x get pxelinux.0Any ideas?
-
I read an article about this today while troubleshooting some TFTP boot problems across subnets. The problem I think has to do with the VPN encapsulation pushing the packet size over the limit during the PXE tftp transfer.
Check out: [url]http://copilotco.com/mail-archives/ltsp.2008/msg00620.html[/url]
I’ll summarize the answer:
[QUOTE]It turns out that the whole issue was the block size of the tftp transfer. For some reason when transferring from a booted pc or a pxe LAN boot this is not an issue. However, when transferring during a VPN pxe boot it is. I have no idea why, but I had to use the -B option in my tftp line in inetd.conf and assign a block size of 1024. Once I restarted inetd the pxe VPN worked. Unfortunately it take over an hour to transfer the files and mount the file system. So…although the transfer problem has been fixed I am back to the drawing board with my LTSP deployment method.[/QUOTE] -
I also had to troubleshoot the same exact issue with FOG over VPN-connected WAN. My observations were identical in that the tftp would work just fine when used from within Windows 7 tftp client or Ubuntu but would NOT work as part of the PXE tftp download process.
As Chad pointed out the issue is in fact with the block size; my remedy was to adjust the IPsec encapsulation only at the tunnel facing HQ where FOG lives. After the remedy was implemented tftp is slow in loading the boot image; however once the file system is mounted the actual payload - that’s the 15G partition image transfer is VERY fast (the sites are connected to the public Internet via 100Mbps to their respective ISPs) so the only downside is the PXE tftp transfer;
Given my observations I must question whether the payload image transfer is in fact using tftp? Why would then the PXE tftp behave so differently from when the large image is being copied onto the HD?
-
Image transfer uses NFS, not tftp. The initial PXE boot sequence uses TFTP to grab the boot file (pxelinux.cfg/default or 01-[mac-address-of-host]) and then to grab the kernel and init files. After that, it’s done and other, faster technologies are used. TFTP is required by the PXE standard from Intel, but once you get through that initial process, you’re free to hand off to better/newer stuff.
-
Aha that’s what I suspected; so then even if one decreases the block size of tftp consequently impacting performance that’s negligible since the big transfer goes via NFS and remains unaffected! Thanks for clarifying this,
-
So I have been experimenting with limiting the TFTP block size to 1024 but I don’t think it is working. The way I am testing is this: I am observing a normal PXE boot with WireShark and looking at the size.
What I did in an attempt to limit the block size was this:
Edit [FONT=Times New Roman]/etc/default/tftpd-hpa and include [/FONT][FONT=Times New Roman]“-B 1024” under the OPTIONS line so the entire tftpd-hpa file looks like this:[/FONT]
[CODE]# /etc/default/tftpd-hpa
FOG Modified version
TFTP_USERNAME=“root”
TFTP_DIRECTORY=“/tftpboot”
TFTP_ADDRESS=“0.0.0.0:69”
TFTP_OPTIONS=“-s -B 1024”
[/CODE]What am I missing?
