[Dnsmasq-discuss] TFTP Boot update "for those who find this problem in the future"
philippe at faure.ca
Tue Aug 25 14:54:37 BST 2009
The issue isn't really with the boot client, but with my network. I
had to pair back the MTU size, so the blocks being handed out are
smaller than what is normal (set to 1400). There is something "fishy"
with my router, ISP and work network, that it wouldn't let me access
the my home server from work. I completely forgot about this
limitation till Simon mentioned blocksizes while debugging this
problem. (I am going to be replacing the router soon).
Because of this limitation, the TFTP had problems. I would suggest to
leave things the way they are, but have the tftp-no-blocksize as an
option. Since my case is the special case, probably not the norm.
Quoting "richardvoigt at gmail.com" <richardvoigt at gmail.com>:
> 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,
>> 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
>>> 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
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
More information about the Dnsmasq-discuss