[Dnsmasq-discuss] [PATCH] add --tftp-mtu option to set the MTU for the TFTP server

[Simon Kelley]

On 03/03/16 23:33, Patrick McLean wrote:
> On Tue, 1 Mar 2016 17:28:35 +0000
> Simon Kelley <simon at thekelleys.org.uk> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 28/02/16 10:47, ?? wrote:
>>> Greetings.
>>>
>>> I think it would be better to be "--tftp-blksize", as this is
>>> already defined in RFC 2347. If some buggy client said he want
>>> bigger, the server could reply --tftp-blksize is the maximum.  
>>
>> I think that is a good suggestion.
>>
>>>
>>> In my understanding of TFTP, it would be strange that a client 
>>> requested a big blksize option then deny fragmented packets. It's
>>> the client said he want a big one, not the server. Why fix this on 
>>> server?  
>>
>> Buggy clients happen. We already have the  --tftp-no-blocksize option
>> for this sort of situation.
>>
>>>
>>> I think it would be a bad idea to request a super big blksize
>>> option to increase performance. I think the blksize option
>>> shouldn't bigger than Ethernet MTU. Because there are buggy client
>>> refusing IPv4 fragment and there Enigmailis no fragmentation in IPv6. To
>>> get more speed, the right way is RFC 7440. However RFC 7440 is
>>> still not widely supported. If writing new code, I think it would
>>> be better to follow RFC 7440 way, and left those old buggy slow
>>> client behind.
>>>
>>
>> tftp is never going to be fast. Making it work with as many clients as
>> possible is the best we can hope.
>>
>> What do people think.
>>
>> - -tft-blocksize-max instead of --tftp-mtu?
>>
> 
> I am not too picky on the naming of the option, but what would
> --tftp-blocksize-max=1300 --tftp-no-blocksize imply?

If --tftp-no-blocksize is set, -tftp-blocksize-max (or, for that matter,
--tftp-mtu) has no effect, since the TFTP server code will not accept a
larger-then-default blocksize, and will use the default value if 512.

--tftp-no-blocksize will also stop the client from _reducing_ the
blocksize below 512, which may not be sensible, but adding

--tftp-blocksize-max=512 would stop the blocksize from being increased
whilst still allowing to be decreased.


> 
> With mtu, it is obvious that it is using this option where it would
> otherwise use the interface mtu, rather than the blocksize.
> 

True, but the _only_ thing it's using the interface mtu for is to set a
ceiling on the blocksize: it has no other effect. The complication is
that the overhead if IP, UDP and TFTP headers is 32 bytes, so

--tftp-mtu=1332

is equivalent to

--tftp-blocksize-max=1300


Cheers,

Simon.