Disable MTFTP

[sb1920alk]

I am PXE booting WinPE 3.0. I'm using tftpd.exe from the Windows 2003 SP2 install disk installed as a service. Most of the time everything is fine. Sometimes, instead of downloaded the boot image, the screen hangs on MTFTP... right after it gets an IP address. The workaround is to restart and try again. Is there a way to disable this entirely in WinPE, or is the problem somewhere else? Maybe the tftp server, DHCP settings, or switch security?

[duveldj]

I am PXE booting WinPE 3.0. I'm using tftpd.exe from the Windows 2003 SP2 install disk installed as a service. Most of the time everything is fine. Sometimes, instead of downloaded the boot image, the screen hangs on MTFTP... right after it gets an IP address. The workaround is to restart and try again. Is there a way to disable this entirely in WinPE, or is the problem somewhere else? Maybe the tftp server, DHCP settings, or switch security?

If it hangs on the TFTP, it's unlikely to be DHCP settings; particularly if you boot successfully some of the time but not all the time. Is the TFTP server itself firewalled? That might cause some issues, if it is. I can only speak in generalities unfortunately, as I'm using an Ubuntu box and syslinux for my PXE booting.

[sb1920alk]

The TFTP server is not firewalled. I'm wondering if it could be the boot file. I'm using pxeboot.com (renamed from pxeboot.n12, so I don't have to press F12 a second time). Also, the only configuring for the service is in the registry, which I found from a blog post. I haven't been able to find any MS documentation on it.

...it did it as I was typing this. For clarification, I rebooted and pressed F12. The screen shows the client mac address and guid, the client IP, mask, and dhcp, the gateway IP, and the last line is MTFTP...

It's almost as if it's waiting for a multicast session, which is not what I want. So, I guess my real question is, where are we in the boot process at this point? Is this still part of the NIC's programming, or part of the pxeboot.com file, or something else? Perhaps the server is too overburdened to handle the additional request?

Second real question is, does anybody know where some MS documentation on tftpd.exe from the 2003 SP2 install media is?

[Tripredacus]

Try using: \boot\x86\wdsnbp.com

which was what I used for WDS/PXE on Server 2003. 2008 is much easier to use since I migrated over, but my old 2003 guide is here if it helps any:

[sb1920alk]

Try using: \boot\x86\wdsnbp.com

which was what I used for WDS/PXE on Server 2003. 2008 is much easier to use since I migrated over, but my old 2003 guide is here if it helps any:

What's the difference between each of these files? I would think that wdsnbp.com would be more likely to be used for multicasting than pxeboot.com.

[Tripredacus]

I'm not sure why I used this rom instead of the regular one. It was a long time ago, maybe the same problems you are experiencing?

[sb1920alk]

I'm not sure why I used this rom instead of the regular one. It was a long time ago, maybe the same problems you are experiencing?

I'll try it out. I used that one originally, but it didn't seem like it was doing anything but calling pxeboot.com. I did notice that it was identifying x64 computers, which took a few seconds that I didn't feel needed to be taken. I'm using x86 WinPE for everything, so the x64 identification isn't really a concern for me.

http://technet.microsoft.com/en-us/library/dd744541(WS.10).aspx

The following outlines the download process.

1.A client is directed (by using DHCP Options or the PXE Server response) to download Wdsnbp.com

2.Wdsnbp.com validates the DHCP/PXE response packet and proceeds to download PXEBoot.com.

...

So, the "validates the PHCP/PXE response packet" might be the step that's causing my problem.

[sb1920alk]

Well, I'm still getting the occasional MTFTP problem with wdsnbp.com. It's as I thought I remembered it to be - When it works, it identifies the x64 hardware, then boots to WinPE. When it doesn't work, it's the same as I described earlier. So, maybe the issue is before the boot file is loaded?

[sb1920alk]

Ack...the page timed me out and I lost what I typed...

...anyways, I've narrowed the problem done to the DHCP server. I have two that serve this subnet. I only get the MTFTP hang when it gets its IP from one of the servers. The other server is fine. I timed it and the hang is around 9 and a half minutes, then it proceeds to boot to WinPE without needing to reboot the machine first. I cannot see any difference in the two DHCP servers, except that they offer different ranges of IPs in the same subnet. All of the scope and server options appear identical. Both of them point to the same TFTP server, which is on a different machine. Both are running x86 2003 SP2 (not R2).

Ideas?

[Tripredacus]

Perhaps you can enable BOOTP (i think WDS uses this, maybe not) on only one of the servers? I might be wrong.

[sb1920alk]

Perhaps you can enable BOOTP (i think WDS uses this, maybe not) on only one of the servers? I might be wrong.

I don't think it's being used on any of the servers. The BOOTP tables on both DHCP servers were empty.

[Tripredacus]

OK so if I am right by what you are saying (you'll have to research this too) is that you get a TFTP timeout on clients booting to PXE where they are on a different subnet or IP block than the PXE or WDS Server? But clients that get an IP on the same IP block or subnet have no problems? If this ends up being the case, definately sounds more like a networking problem rather than with just WinPE.

[sb1920alk]

OK so if I am right by what you are saying (you'll have to research this too) is that you get a TFTP timeout on clients booting to PXE where they are on a different subnet or IP block than the PXE or WDS Server? But clients that get an IP on the same IP block or subnet have no problems? If this ends up being the case, definately sounds more like a networking problem rather than with just WinPE.

No, that's not it. All of the servers are on a separate subnet from the client machines. This includes the DHCP servers and the TFTP server.

The DHCP servers offer different ranges of IPs in the same subnet. That way it doesn't matter if one of them is offline, or which of them answers the client request. It's not exactly in half, but let's say that we split the subnet's range of valid host IP addresses in half. The first half is offered by the first DHCP server, and the second half is offered by the second DHCP server. Something like 10.0.0.1/24 - 10.0.0.127/24 for one server and 10.0.0.128/24 - 10.0.0.254/24 for the other.

Also, it's not a TFTP timeout we're experiencing, it's an MTFTP timeout.

[sb1920alk]

Problem is solved. DHCP option 43 was set to 0104000000FF on the server that wasn't working and 010400000000FF on the server that was. I'm not sure what that option's purpose is, or who put it there, but after the extra two 0's were added to the first server, PXE boot is working regardless of which server provides an IP address to the client.

Thanks for your help

[Tripredacus]

Interesting. I found a bunch of info about Option 43, but I don't feel like reading too much about it. In case anyone else does, check these out:

http://publib.boulder.ibm.com/infocenter/tivihelp/v11r1/index.jsp?topic=/com.ibm.tivoli.tpm.ins.doc/install/tins_dhcpconfig43.html

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00808714fe.shtml

http://wiki.novell.com/index.php/Using_DHCP_option_43_%28Vendor_Extensions%29