Lenovo (m)70e tftp problem

[rb3314]

I have an older model Lenovo desktop with a Marvel Yukon Nic
It is showing Yukon PXE v6.62.1.3 Pre Boot v2.1

During the PXE boot it is giving an error:
PXE-T01: File not Found
PXE-E3B: TFTP Error - File Not Found

The best lead I have found is that a tcpdump shows the tftp file name with garbage

the dump shows
tftp: [udp sum ok] 31 RRQ “undionly.kpxeM-^?” octet size 0

for many other models and brands of laptops that work just fine that same dump shows
tftp: [udp sum ok] 31 RRQ “undionly.kpxe” octet size 0

Is there some manipulation that can be done to the DHCP helper (options 66 & 67) or anything in tftp settings that might help that brand/version of Nic properly connect?

[Wayne Workman]

@rb3314 said in Lenovo (m)70e tftp problem:

During the PXE boot it is giving an error:
PXE-T01: File not Found
PXE-E3B: TFTP Error - File Not Found
The best lead I have found is that a tcpdump shows the tftp file name with garbage

More importantly, what IP address is the request going to? Is it even correct? Also, what’s doing your DHCP?

[rb3314]

The IP address for TFTP is to our CentOS7 server running FOG, DHCP is handled by the Cisco Switch. There are no hops in between it and the switch.

[rb3314]

Also, This same Lenovo model alternatively comes with a Realtek Nic which Pxe boots just fine.

[Wayne Workman]

@rb3314 in the TCP dump, where the box gets a DHCP lease, what does DHCP give to it for option 067? We know the box is requesting the wrong filename. I’m wondering if DHCP is giving the correct file name.

[george1421]

@rb3314 said in Lenovo (m)70e tftp problem:

the dump shows
tftp: [udp sum ok] 31 RRQ “undionly.kpxeM-^?” octet size 0
for many other models and brands of laptops that work just fine that same dump shows
tftp: [udp sum ok] 31 RRQ “undionly.kpxe” octet size 0

I’ve seen this before. If you look at the tcpdump hex codes (or wireshark). after the e in .kpxe the next byte needs to be 0x00 (end of string). There is also (at the beginning of the) undionly.kpxe the hex byte just to the left of the u is the number of bytes in that dhcp string.

Ok with all of that said, there are some pxe boot roms that honor the byte count other boot rooms look for the 0x00 (end of text string) byte. If you look at the hex codes for “undionly.kpxeM-^?”, you will probably find a 0x00 after the question mark.

So what can you do? Well this is a dhcp server / pxe boot rom issue (be aware this ISN’T a Fog issue). You need to change one of the two to be happy. You probably need to correct your dhcp server so it sends the end of text string. Certain flavors of ISC-DHCP have this same issue.

If you can’t fix your dhcp server, then if needed you can use the dnsmasq on the FOG server to supply the pxe boot info, where your main dhcp server would handle the dhcp IP assignments only.

[rb3314]

@george1421

Thank you for the insight. Let me look at those items a little further.