>>>>> "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.
Attachment:
pgpJ38n8QDG8a.pgp
Description: PGP signature