It seems that tftpd-hpa is more suitable at serving arbitrarily large files (greater than 65535 blocks long; with pxelinux.0 using a default block size of 1408 this is 92,273,280 bytes) as atftpd will complain in the log stating "Requested file to big, increase BLKSIZE". I saw that a while back HPA mentioned that atftpd was probably more scalable (number of clients) while tftpd-hpa is more portable. It looks like tftpd-hpa supports block number rollover while atftpd doesn't seem to (unless it's a runtime option that I can't find or a compile time option). On the flip side, files this big are probably more suitably handled by another means (gpxelinux.0 rather than pxelinux.0 with the large data files on a standard web server). -- -Gene
On 07/09/2010 10:36 AM, Gene Cumm wrote:> It seems that tftpd-hpa is more suitable at serving arbitrarily large > files (greater than 65535 blocks long; with pxelinux.0 using a default > block size of 1408 this is 92,273,280 bytes) as atftpd will complain > in the log stating "Requested file to big, increase BLKSIZE". I saw > that a while back HPA mentioned that atftpd was probably more scalable > (number of clients) while tftpd-hpa is more portable. It looks like > tftpd-hpa supports block number rollover while atftpd doesn't seem to > (unless it's a runtime option that I can't find or a compile time > option). > > On the flip side, files this big are probably more suitably handled by > another means (gpxelinux.0 rather than pxelinux.0 with the large data > files on a standard web server). >Unfortunately atftpd development seems to have stopped entirely, and not supporting block rollover pretty much kills it. Increasing blksize is not an option in a lot of cases, since most embedded TFTP stacks don't handle fragmented IP packets well. PXELINUX uses 1408 bytes to fit in an Ethernet frame and still have 60 bytes to spare in case there is a tunneling solution somewhere in the system. 60 bytes is a bit small for that, of course. There is a very low-level effort at getting TFTP support into Apache, but it seems to have gone on since 2003 with not much results. tftp-hpa is fairly constrained by the "must be psychotically portable" requirement. That, fortunately, has made it widely adopted which is good since it solves a lot of serious problems. I also don't have much time to maintain it these days, which is a real problem. -hpa
Gene Cumm wrote:> It seems that tftpd-hpa is more suitable at serving arbitrarily large > files (greater than 65535 blocks long; with pxelinux.0 using a default > block size of 1408 this is 92,273,280 bytes) as atftpd will complain > in the log stating "Requested file to big, increase BLKSIZE". I saw > that a while back HPA mentioned that atftpd was probably more scalable > (number of clients) while tftpd-hpa is more portable. It looks like > tftpd-hpa supports block number rollover while atftpd doesn't seem to > (unless it's a runtime option that I can't find or a compile time > option). > > On the flip side, files this big are probably more suitably handled by > another means (gpxelinux.0 rather than pxelinux.0 with the large data > files on a standard web server). > > -- > -GeneI think atftpd-0.7_circumvent_tftp_size_restrictions.patch [1] fixes the issue. [1] http://lists.opensuse.org/opensuse-commit/2008-09/msg00732.html Sebastian