Re: tftp protocol

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 17 Oct 2009 23:41:52 -0400
    From:        Miles Nordin <carton%Ivy.NET@localhost>
    Message-ID:  <oqbpk5l667.fsf%castrovalva.Ivy.NET@localhost>

  | but what they should have done is maybe not a
  | good reason to stubbornly desupport it,

It isn't a question of de-supporting something, but of how can it
possibly be supported when we don't know what it is?

If there was one agreed way that everyone used to transfer large
files (bigger than tftp was designed to support, even with the large
block extension), that would be fine, but there isn't.

We can't support all of the kludges that exist, as some of them
are incompatible with each other - I certainly agree than when faced
with a weird tftp client, the usual (and often only rational) answer
is to obtain, or create, a tftp server that interoperates with that
client.   But NetBSD can't do that, we have no idea what weird clients
the various users will need to support, and have no rational reason to
prefer one particular set of weird clients over another.   All that
is rational to do (in the base system) is to support the part of tftp
that is more or less standard, and forget all the rest.

On the other hand, it is perfectly reasonable to create pkgsrc packages
for any other tftpd variant that you can find, or create, so that people
who have one of the weird clients can more easily handle it.   It might
even be reasonable to create a tftpd multiplexor, that would receive
the RRQ/WRQ initial packets, and based upon (perhaps) the OUI in the MAC
address (assuming there is one, and the client is on the local LAN) of
the client, or perhaps its IP address, or even the file name it is
requesting, then exec a suitable tftpd process to handle the request
in whatever weird way that client needs - that could also go in pkgsrc...

kre