[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 05:14:55 BST 2009


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.

On Mon, Aug 24, 2009 at 8:01 PM, Philippe Faure<philippe at faure.ca> wrote:
> It would seem that the network MTU was my limiting factor.  With
> Simon's Help, we were able to find the problem and solution.
>
> My config file didn't mention (being that it was too old) the switch,
> tftp-no-blocksize
>
> Adding it, and restarting dnsmasq, the new system booted straight to
> the install page.
>
> I am using a boot client that is part of the motherboard.
> MB: Asus, M4N78 Pro
> Nvidia Boot Agent version: 249.0542.
>
> Snip from Simon's Email
>
>> OK, it looks like the client is asking for a blocksize (ie packetsize)
>> of 1456 bytes, and that's too big for your network. Because of that the
>> packets are getting fragmented and that's really confusing the client:
>> in the end the client does something really strange which provokes the
>> "unsupported request" error.
>>
>> Try adding
>> tftp-no-blocksize
>>
>> to /etc/dnsmasq.conf. That will cause dnsmasq to reject the request from
>> the client for bigger blocks, and may be enough to make it all work.
>> Alternatively if you can increase the MTU on the network that might fix
>> things.
>
>
> Philippe
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>



More information about the Dnsmasq-discuss mailing list