Re: [Ltsp-discuss] TFTP: Open Timeout error on client (or Transfer timed out error on server)

[John H. <lt...@pr...>]

On 11/19/2012 1:23 PM, John Hupp wrote:
> I had a thread named "LTSP-PNP on Lubuntu: Chromium 
> ERR_NAME_RESOLUTION_FAILED," but am starting a new thread to 
> accurately reflect the problem I'm now wrestling with.
>
> I'm trying to troubleshoot an LTSP (the new LTSP-PNP) client boot 
> problem under Quantal.  I installed with a single NIC per 
> https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
>
> The problem is that the LTSP client, after successfully getting DHCP 
> assignments, fails to download the pxelinux boot image.  It reports 
> "PXE-E32: TFTP open timeout."
>
> To be more specific on the DHCP assignments, it identifies my hardware 
> router as the DHCP server and the default gateway.  It identifies the 
> LTSP server as proxy and boot server.
>
> I can also run this on the server itself to get a similar failure:
> $ cd /tmp
> $ tftp 192.168.1.102 -v -m binary -c get /ltsp/i386/pxelinux.0
> mode set to octet
> Connected to 192.168.1.102 (192.168.1.102), port 69
> getting from 192.168.1.102:/var/lib/tftpboot/ltsp/i386/pxelinux.0 to 
> pxelinux.0 [octet]
> Transfer timed out.
>
> A CRITICAL NOTE: This is using the default network-manager to 
> configure the network interface (using the default DHCP configuration, 
> and the connection is "Available to all users").  Apparently 
> network-manager also runs or works with dnsmasq, which provide DHCP 
> and TFTP servers.
>
> When I had TFTP and DHCP errors booting the client under LTSP5 and 
> Precise, I learned that the usual work-around was to configure the 
> network interface(s) via /etc/network/interfaces.  I think this solved 
> some sort of a timing problem with the relevant services during bootup.
>
> But that approach is apparently deprecated under Quantal and 
> LTSP-PNP.  In fact, I can use that approach to get the client to boot 
> successfully, but it introduces a new problem on server and client: 
> DNS resolution fails.  I understand that this happens because a 
> non-default /etc/network/interfaces causes ifupdown to configure 
> network interfaces instead of network-manager, but now network-manager 
> is being relied upon to provide DNS resolution with dnsmasq.
>
> I can fix the DNS resolution problem by creating 
> /etc/resolvconf/resolv.conf.d/tail with contents:
> nameserver (my nameserver 1)
> nameserver (my nameserver 2)
>
> -----------------------
>
> But instead of patching up the old approach, I'd like to get the new 
> approach working right.
>
> Looking for others who have dealt with the same problem, I have not 
> found much, but there was this 2010 thread: 
> http://ubuntuforums.org/showthread.php?t=1503710
>
> One of the posters (#6) says that when he disabled NAT, TFTP started 
> working.  I don't know what that means for me in my setup.  But it did 
> get me to thinking about my little network running from my 
> consumer-class hardware router.  Is dnsmasq in conflict with a service 
> being provided by the router?  Is my router's firewall blocking FTP 
> communication between LTSP client and server?
>
> If those are fruitless questions, then I would wonder why TFTP works 
> when I use /etc/network/interfaces and ifupdown to configure the 
> network interface, and it fails when network-manager governs instead.
>
> By the way, this installation has seen very little modification.  I 
> installed Quantal on a newly-formatted hard drive, allowing it to use 
> its default partitioning.  I installed LTSP-PNP.  I set up a scanner 
> via already-installed SANE.  Also apcupsd for the sake of use with a 
> UPS.  I installed HPLIP and an HP Laserjet printer.
>
> -----------------------------
>
> My (as-installed default) ltsp-server-dnsmasq.conf in case that is of 
> interest:
>
> # Configures dnsmasq for PXE client booting.
> # All the files in /etc/dnsmasq.d/ override the main dnsmasq 
> configuration in
> # /etc/dnsmasq.conf.
> # You may modify this file to suit your needs, or create new ones in 
> dnsmasq.d/.
>
> # Log lots of extra information about DHCP transactions.
> #log-dhcp
>
> # IP ranges to hand out.
> dhcp-range=192.168.67.20,192.168.67.250,8h
>
> # If another DHCP server is present on the network, you may use a 
> proxy range
> # instead. This makes dnsmasq provide boot information but not IP leases.
> # (needs dnsmasq 2.48+)
> dhcp-range=192.168.1.0,proxy
>
> # The rootpath option is used by both NFS and NBD.
> dhcp-option=17,/opt/ltsp/i386
>
> # Define common netboot types.
> dhcp-vendorclass=etherboot,Etherboot
> dhcp-vendorclass=pxe,PXEClient
> dhcp-vendorclass=ltsp,"Linux ipconfig"
>
> # Set the boot filename depending on the client vendor identifier.
> # The boot filename is relative to tftp-root.
> dhcp-boot=net:pxe,/ltsp/i386/pxelinux.0
> dhcp-boot=net:etherboot,/ltsp/i386/nbi.img
> dhcp-boot=net:ltsp,/ltsp/i386/lts.conf
>
> # Kill multicast.
> dhcp-option=vendor:pxe,6,2b
>
> # Disable re-use of the DHCP servername and filename fields as extra
> # option space. That's to avoid confusing some old or broken DHCP clients.
> dhcp-no-override
>
> # We don't want a PXE menu since we're using a graphical PXELinux menu.
> #pxe-prompt="Press F8 for boot menu", 3
>
> # The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
> # Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
> pxe-service=X86PC, "Boot from network", /ltsp/i386/pxelinux
>
> # A boot service type of 0 is special, and will abort the
> # net boot procedure and continue booting from local media.
> #pxe-service=X86PC, "Boot from local hard disk", 0
>
> # Comment the following to disable the TFTP server functionality of 
> dnsmasq.
> enable-tftp
>
> # The TFTP directory. Sometimes /srv/tftp is used instead.
> tftp-root=/var/lib/tftpboot/
>
> # Disable the DNS server functionality of dnsmasq by setting port=0
> port=0
>
> # Don't listen on lo, to prevent conflicts with Ubuntu's local 
> resolver hack (LP: #959037).
> #except-interface=lo
> #bind-interfaces

Trying to make some further progress on this, I have been looking at the 
dnsmasq man page (it's big!).

It seems to me that I need to get into position to examine whether 
dnsmasq started up with the right configuration.  Does LTSP-PNP start 
its own instance of dnsmasq?  If so, can I restart that particular 
instance, and where does it launch from?