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

[Patrick McLean]

Some BIOSes don't like fragmented packets, and it's useful to be able
to netboot over MTU limited links, but it's annoying to set the
interface MTU for only TFTP. This patch adds a tftp-mtu option to
override getting the MTU from the interface.

[Simon Kelley]

Thanks for that.


I've somewhat reworked it so that the supplied MTU is a ceiling (ie,
you can reduce the used MTU with the option, but not increase it.)
That would seem to be safer.


In the git repo now. Please shout if I've broken things for you.



cheers,

Simon.


On 24/02/16 18:24, Patrick McLean wrote:
> Some BIOSes don't like fragmented packets, and it's useful to be
> able to netboot over MTU limited links, but it's annoying to set
> the interface MTU for only TFTP. This patch adds a tftp-mtu option
> to override getting the MTU from the interface.
>
>
>
> _______________________________________________ Dnsmasq-discuss
> mailing list Dnsmasq-***@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>

[五月]

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.

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?

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 is 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.

Dnsmasq is great~ >_<


ÎåÔÂ
2016.2







> To: dnsmasq-***@lists.thekelleys.org.uk
> From: ***@thekelleys.org.uk
> Date: Wed, 24 Feb 2016 22:06:15 +0000
> Subject: Re: [Dnsmasq-discuss] [PATCH] add --tftp-mtu option to set the MTU for the TFTP server
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Thanks for that.
>
>
> I've somewhat reworked it so that the supplied MTU is a ceiling (ie,
> you can reduce the used MTU with the option, but not increase it.)
> That would seem to be safer.
>
>
> In the git repo now. Please shout if I've broken things for you.
>
>
>
> cheers,
>
> Simon.
>
>
> On 24/02/16 18:24, Patrick McLean wrote:
> > Some BIOSes don't like fragmented packets, and it's useful to be
> > able to netboot over MTU limited links, but it's annoying to set
> > the interface MTU for only TFTP. This patch adds a tftp-mtu option
> > to override getting the MTU from the interface.
> >
> >
> >
> > _______________________________________________ Dnsmasq-discuss
> > mailing list Dnsmasq-***@lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBCAAGBQJWzilWAAoJEBXN2mrhkTWi45oP/237SLQJbUF8fHyuNJXJWarq
> NuZzBTxa0o+5CaHsCYxqn0iU3I+0Df2UCNdmRxyn6y/B2ODRggkPWJ0cuFQ9sxFZ
> F434mql4jTdbg+6Kep9+LHmBmA1jUucc5Buo3CWcSRUbYU2vELoVeSqEaEHMcnCW
> 134ykcGKZFdp85il/yq6gNGV43dQIvACN9zt5FDMoVHZaJgpV3lxunoW28qnOmv0
> XTuO9YRF8Ay7/i8eGkiBq09i4EtzIdPNKSWClJYVCBmZp6870dztCgl0J72Q426c
> tlMoV8jSUuHhOkAdc2CE2Bm9U4rlxYK1HT1cpoC9KJSPbZIc39ZWBRkprFfkVkex
> /iabgdoFwtZxc6I5qj9ER47Tx3Wz5Hm6VYV5xGuJCzzC9qmTTgCul+Fbv71/X3qN
> fk76WCQPNibOIElJutDMZ2k0m1esuPLmY5aA6PnmulOM8gOEvp6sUeJU79BttKsE
> RrbK3yG2hhj08oEq1tI7lPI2+J1t3yLXT0/66GqFloljjT50aCalOYtqngg1JafC
> kyWv2C/8AEoEojn8o2nDO1Tpw9+kenfAZv3ixLM1fAMSQv3+uhnWPq6mevgvktd3
> eRbmNAKFH4IEaZsM07WdzxANfiJiZYt2vRzPwYItDjBBjzTleheqkzkdQUCCFA+P
> G5/idnxX3C1Wv0d+YHOS
> =F8pO
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-***@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Simon Kelley]

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 is 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.
>
> Dnsmasq is great~ >_<
>
>
> ?? 2016.2
>
>
>
>

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?


Cheers,

Simon.

>
>
>
>> To: dnsmasq-***@lists.thekelleys.org.uk From:
>> ***@thekelleys.org.uk Date: Wed, 24 Feb 2016 22:06:15 +0000
>> Subject: Re: [Dnsmasq-discuss] [PATCH] add --tftp-mtu option to
>> set the MTU for the TFTP server
>>
> Thanks for that.
>
>
> I've somewhat reworked it so that the supplied MTU is a ceiling
> (ie, you can reduce the used MTU with the option, but not increase
> it.) That would seem to be safer.
>
>
> In the git repo now. Please shout if I've broken things for you.
>
>
>
> cheers,
>
> Simon.
>
>
> On 24/02/16 18:24, Patrick McLean wrote:
>>>> Some BIOSes don't like fragmented packets, and it's useful
>>>> to be able to netboot over MTU limited links, but it's
>>>> annoying to set the interface MTU for only TFTP. This patch
>>>> adds a tftp-mtu option to override getting the MTU from the
>>>> interface.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dnsmasq-discuss mailing list
>>>> Dnsmasq-***@lists.thekelleys.org.uk
>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>>
>
>>>>
>>>>
>>
>> _______________________________________________ Dnsmasq-discuss
>> mailing list Dnsmasq-***@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
>
>
>
> _______________________________________________ Dnsmasq-discuss
> mailing list Dnsmasq-***@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>

[Patrick McLean]

On Tue, 1 Mar 2016 17:28:35 +0000
Simon Kelley <***@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 is 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?

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

>
> Cheers,
>
> Simon.
>
> >
> >
> >
> >> To: dnsmasq-***@lists.thekelleys.org.uk From:
> >> ***@thekelleys.org.uk Date: Wed, 24 Feb 2016 22:06:15 +0000
> >> Subject: Re: [Dnsmasq-discuss] [PATCH] add --tftp-mtu option to
> >> set the MTU for the TFTP server
> >>
> > Thanks for that.
> >
> >
> > I've somewhat reworked it so that the supplied MTU is a ceiling
> > (ie, you can reduce the used MTU with the option, but not increase
> > it.) That would seem to be safer.
> >
> >
> > In the git repo now. Please shout if I've broken things for you.
> >
> >
> >
> > cheers,
> >
> > Simon.
> >

[Simon Kelley]

On 03/03/16 23:33, Patrick McLean wrote:
> On Tue, 1 Mar 2016 17:28:35 +0000
> Simon Kelley <***@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.