Carlos Carvalho wrote: > Simon Kelley (si...@thekelleys.org.uk) wrote on 3 August 2008 21:02: > >Carlos Carvalho wrote: > >> I have > >> > >> tftp-root=/var/remoteboot > >> > >> in dnsmasq.conf. For a machine I have in dhcp-options: > >> > >> ometepe,vl5,67,"/tftpboot/pxelinux.0" > >> > >> In the log there is > >> > >> dnsmasq[16090]: sent size: 21 option: 67:bootfile-name > 2f:74:66:74:70:62:6f:6f:74:2f:70:78:65... > >> > >> Checking with the ascii table this looks correct. However, the client > >> says it cannot find /var/remoteboot/tftpboot/pxelinux.0. Removing the > >> tftp-root= setting in dnsmasq.conf makes the client get the correct > >> /tftpboot/pxelinux.0 so the problem seems to be in dnsmasq. > > > >It's behaving as designed: You've set the TFTP root to be > >/var/remoteboot, so filenames are relative to that root. The client asks > >for /tftpboot/pxelinux.0 so dnsmasq tries to send > >/var/remoteboot/tftpboot/pxelinux.0 which doesn't exist, so it returns > >an error, which inlcudes a message giving the complete pathname. That's > >what the client it displaying. > > > >Note that if the filename includes a leading /, dnsmasq will also try > >assuming it's an absolute pathname, but only if the first part of the > >filename matches the tftp-root. > >> > >> In a first look I didn't find any places where this concatenation > >> could happen. Note that the tftp server is not the machine running > >> dnsmasq in this case. > >Now I'm confused. What is the TFTP server? > > That's the whole point I don't understand. Here are the options for > the machine: > > ometepe,vl5,3 > ometepe,vl5,6 > ometepe,vl5,28 > ometepe,vl5,15 > ometepe,vl5,66,"192.168.5.74" > ometepe,vl5,67,"/tftpboot/pxelinux.0" > > The IP of the machine running dnsmasq is 192.168.5.18. So what should > happen is > > client broadcasts dhcp request > 192.168.5.18 answers saying tftp server is 192.168.5.74 > client asks /tftpboot/pxelinux.0 to 192.168.5.74 > client never heards about /var/remoteboot... > > That's why I gave the log line with the value of boot-filename above. > > Hmm... Looking at the log again the whole transaction is: > > DHCP packet: transaction-id is 3866001293 > Available DHCP subnet: 192.168.5.1/255.255.255.0 > Vendor class: PXEClient:Arch:00000:UNDI:002001 > DHCPREQUEST(eth0.5) 192.168.5.71 00:1e:8c:7f:6e:e6 > DHCPACK(eth0.5) 192.168.5.71 00:1e:8c:7f:6e:e6 ometepe > requested options: 1:netmask, 2:time-offset, 3:router, 5, 6:dns-server, > requested options: 11, 12:hostname, 13:boot-file-size, 15:domain-name, > requested options: 16:swap-server, 17:root-path, 18:extension-path, > requested options: 43:vendor-encap, 54:server-identifier, 60:vendor-class, > requested options: 67:bootfile-name, 128, 129, 130, 131, 132, > requested options: 133, 134, 135 > server name: 192.168.5.74 > tags: vl5, ometepe, known > sent size: 1 option: 53:message-type 05 > sent size: 4 option: 54:server-identifier c0:a8:05:12 > sent size: 4 option: 51:lease-time ff:ff:ff:ff > sent size: 4 option: 1:netmask ff:ff:ff:00 > sent size: 7 option: 12:hostname 6f:6d:65:74:65:70:65 > sent size: 21 option: 67:bootfile-name > 2f:74:66:74:70:62:6f:6f:74:2f:70:78:65... > > So it seems the client isn't requesting option 66 and is asking the > dhcp server for pxelinux. > > If this is the case would --dhcp-option-force help? Would the tftp > server be available to pxelinux in the client? > > >> The dnsmasq log shows no TFTP request but I > >> vaguely remember Simon saying that these are not logged. > >> > >File-not-found is not logged, since it clutters up the log with lots of > >failed attempts by PXELinux to read possible config files. > > But it helps in situations like this one. One can always grep them > out, and compression ratio is very high for repetitive parts so it > won't fill the disk. > >
I've come across many PXE ROMS which are buggy, and just don't work if the DHCP server and TFTP server are on different machines. My guess is that you have one of those. Simon.