>>>>> "re" == Robert Elz <kre%munnari.OZ.AU@localhost> writes: re> If there was one agreed way that everyone used to transfer re> large files (bigger than tftp was designed to support, even re> with the large block extension), that would be fine, but there re> isn't. okay. re> We can't support all of the kludges that exist, as some of re> them are incompatible with each other which ones? re> All that is rational to do (in the base system) is to support re> the part of tftp that is more or less standard, and forget all re> the rest. re> On the other hand, it is perfectly reasonable to create pkgsrc re> packages [...] to whatever extent the incompatible kludge problem is real, ``maybe''. but so far I think the problem is hypothetical, and we've already got a patch posted for windows pxe that fixes one bogus client and probably breaks nothing, which your reasoning says shouldn't be committed---that's the part I disagree with. I think you secretly want to boot the tftpd with kludges out to pkgsrc for taxonomy reasons. But maintaining two tftpd's seems really unlikely to happen. Maintaining one is hard enough, the care factor is so low with this stuff---I know myself, you just bang on it until it works then walk away, because the clients are all buggy proprietary flash-in-the-pan junk---but this means everyone has to reinvent the wheel and realize the broken piece is tftpd, something you thought was too simple to break. I predict someone will read what I'm writing in 2014 and find that working windows pxe tftp large file patch posted yesterday still languishing in these mail archives, and he will add it manually to his local branch. To that person I would suggest: use tftpd-hpa instead. It's Linux's fork of the OpenBSD tftpd, and it's maintained. it works with alpha srm firmware in at least one case where netbsd's didn't. It has a rollover option so that not only will it send >32MB files, but you can specify whether you want the block counter to roll over to 1 or to 0, so you can try both with your client and see which one works---I guess they found an incompatbile aspect to the kludgery after all. I've not tried it, but by 2014 it will probably include other important kludges the NetBSD tftpd lacks.
Description: PGP signature