[Dnsmasq-discuss] TFTP Boot update "for those who find this problem in the future"

richardvoigt at gmail.com richardvoigt at gmail.com
Tue Aug 25 14:52:23 BST 2009

On Tue, Aug 25, 2009 at 4:31 AM, Simon Kelley<simon at thekelleys.org.uk> wrote:
> richardvoigt at gmail.com wrote:
>> I can't think of a single circumstance where a manufacturer-provided
>> boot PROM would have more appropriate network-specific settings than
>> the TFTP server configuration.
>> Maybe tftp-no-blocksize should be set by default (with a
>> tftp-honor-blocksize to negate it).
>> But I don't use BOOTP remote booting, so Simon probably has good
>> reasons for doing things the way they are.
> Setting tftp-no-blocksize forces 512-byte blocks and makes the already-slow
> TFTP transfer three times slower. Since most netbooting happens over a local
> net which is a physical ethernet with well-known MTU, it makes sense for the
> client to request a blocksize suitable for that media.

Is that 512 adjustable?  b/c the local dnsmasq admin can surely make a
better choice than the PROM developer.  Plus I think most tcp/ip
stacks automatically determine path MTU, don't know if dnsmasq could
retrieve the value estimated for some other local host on the same
interface as a reasonable default in the absence of configuration.
There's probably no portable way to do that though.

Also, a quick look at the protocol indicates that "only one packet may
be in-flight at a time" but that data packets and acknowledgements all
carry sequence numbers, I'm not sure what exactly about the format
requires stop-and-wait.

> It's not clear to me why the MTU on Philippe's network is smaller, but I
>  think a small MTU is a fairly rare occurrence. Even when it does happen, it
> shouldn't be a show stopper: that takes badly broken client firmware that
> has clearly never had any code-paths other than the most common ones tested.

Passing through a switch which adds VLAN marking often causes
fragmentation of maximally sized payloads.  Wireless hops could change
MSS as well.

But maybe the best solution would just be to mention tftp-no-blocksize
in the error message as a possible fix.

> Cheers,
> Simon.

More information about the Dnsmasq-discuss mailing list