• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 133
  • Last Modified:

File This Under Weird - PXE Stops TFTP Transmission When Display Is Disconnected

I am bringing a PXE server online (Symantec Ghost Solution Suite 3.1 Build 502) using the integrated Altiris PXE Server software.

Once I had everything up and running (hats off to Symantec to their "thorough" documentation) I was very disappointed with the transfer speeds (getting ~100-200 Kbps) to get the PE files downloaded onto the client and boot into a Windows environment.

A little bit of searching revealed "Double Your PXE Boot Speed!" http://www.symantec.com/connect/articles/double-your-pxe-boot-speed written by a Symantec Employee, advising to not use Altiris PXE MTFTP Server, and instead replace it with OpenTFTP (gotta love it!).

Once I had the necessary configs down, I was able to pull down 20 Mbps! I was so excited that I went ahead and switched over to the other PC I had on my KVM and got that guy going to. This is where the weirdness started.

When I switched back to the original PC, I found that the transfer had again slowed to a crawl (forehead meet desk). And worse, when I checked on the second PC, it too went to a crawl.  I checked around the forums and everything pointed to adjusting the block size. First I went big as suggested here (http://www.alexandreviot.net/2015/07/09/sccm-2012-how-to-increase-tftp-pxe-boot-speed/), then started going small as I kept having issues with the speeds cutting out whenever I switched over to the second PC and got that going.

Now some of you might be thinking "Its the network!" Well that was where I was going, but had no desire to go down that rabbit hole. So I took a beat and said to my self, what exactly is happening here?

1. Start PXE Boot on PC 1
2. Verify Speed on Server as 20+
3. KVM to PC 2
4. Start PXE Boot on PC 2
5. Verify Speed on Server and see in history that PC 1 dropped off

That's when I realized that it had nothing to do with turning on PC 2!

For those who do not follow, start on 1, see speed, switch to PC 2, see speed cut out.

It was the switching of inputs/outputs!!!!!
(Audible whack of forehead into closest wall)

Sure enough, I can reliably get the transfer to slow to a crawl by removing the display port cable on the rear of the PC (USB does not seem to affect it)

What I am working with:
Dell Optiplex 3040 Micro with a Realtek PCI-E Gigabit Ethernet Controller (Driver on dell website has file name Network_Driver_9YMJF_WN64_2.43.2015.709_A00.EXE)

Does anyone have an idea as to how I can switch displays without killing the downloads???
Anthony Weiss
Anthony Weiss
  • 6
  • 3
3 Solutions
Michael PfisterCommented:
Don't know what it has to do with DisplayPort but I found this regarding slow PXE.


Its WDS but they are patching the OS boot file.
Anthony WeissAuthor Commented:
Interesting, but the PE boot is a Windows 10 environment. Your comment did prompt me to test with the PXE load in with the Symantec-provided Linux PE.  Same results when DP is unplugged.  

Also conducted testing with the built in HDMI port (only display outs are 1 DP and 1 HDMI). Same results with the HDMI :(

Maybe this is a firmware / UEFI issue? It seems like a really weird presentation though, especially since they are two different manufacturers (Realtek - Ethernet, Intel - On Board Video)
I had weird issues with KVMs and PXE booting back in 2000 when we created a solution for INtel electronic classrooms.
Interrupt storms, mice not detected when teh KVM was looping one PC after the other etc.
At first I would check that the BIOS/PXE code is up to date and, if it is and the problem can be reproduced, file a bug report with the OEM with step-by-step details to reproduce the bug.
Then, try not to have any KVM or use another KVM.
Try to PXE boot with headless clients and monitor the process speed one way or another (I used to have systems that would send packets or create files on shared folders at certain points of the boot process so that we could measure the elapsed time with various conditions). Run the very same test with monitors attached to the clients and see if something is obviously different.

You can also use some other PXE infrastructure. Symantec/Altiris relies on very old code (some even coming from 3Com's LanDrive, a 1999 product). To run some test, you do not need a real PXE infrastructure, DHCP and TFTP are enough. Check my article to learn more about DHCP options 66 and 67 that will make it doable to use PXE only with DHCP and TFTP :
NEW Internet Security Report Now Available!

WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network.  Check out this quarters report on the threats that shook the industry in Q4 2017.

Anthony WeissAuthor Commented:

Thanks for the suggestions.  I did pull the KVM out of the equation when I tested for HDMI (it is a DP KVM).  My thinking has been on the lines of just getting the job done, and booting these guys up w/o monitors and configuring the PXE Server to boot directly into the PE environment.  Not ideal since there is no way for me to isolate to a subnet (any suggestions would be welcome), but doable, as long as it is for a short time period.

I will check for the BIOS / UEFI version as well, though I do not believe there has been an update as of yet for this model.
Anthony WeissAuthor Commented:

Oh Yeah, and that article you wrote, AWESOME! I stumbled upon it when I was getting the config setup.  Symantec has great documentation!
Anthony WeissAuthor Commented:
I took a look @ the BIOS / UEFI, and saw it was on 1.3.5. Latest version was 1.4.6, released July 19 2016. Even cooler, it announced a possible fix!

Fixes & Enhancements
-Addressed DP/HDMI operates abnormal.

Don't know what they fixed though, because the issue is still present :(
You should try to file a bug report, including step-by-step instructions to reproduce the issue.

Just to be sure, what NBP do you use?

Do you know you can use iPXE and wimboot to directly boot into a PE environment?
Winboot boots off any bootable wim image. It uses an http server, thus is much faster than using TFTP. I used it with IIS without any issue.
get it here http://ipxe.org/wimboothttp://ipxe.org/wimboot
get and configure iPXE for PXE-chainloading here http://ipxe.org/howto/chainloading (you may have to "Save As" the file http://boot.ipxe.org/undionly.kpxe )

It uses a totally different NBP and may be well suited for your needs.

Maybe the issue you see relies in interactions between your PXE NBP and second/third/whatever stage programs, the BIOS/UEFI/PXE code and the hardware.

Worth a try I would say
Anthony WeissAuthor Commented:
Well, I have a "resolution" to this issue.

My primary goal was to open a Windows PE session to run Dell's .exe BIOS deployment tool to prepare the units for an image of Windows 10 (their default config is BIOS, not UEFI, with Secure Boot, and a number of other important features turned off), then image the units.

What I have discovered, is the issue itself is isolated to only the BIOS PXE environment.  Once I get the initial preparation out of the way and reboot into the UEFI PXE environment, everything is peachy!  So..., I am going to leave well enough alone, run a forced, automated boot for PXE, headless, then reboot into UEFI, where I can go crazy with video connections.

Thanks all for the help.
Thanks for the update (and the points).
In the future, you may want to give a try to iPXE/wimboot etc, these are very nice "PXE" tools
Anthony WeissAuthor Commented:
I was able to independently find a work-around that met my need, as well as others in similar situations with similar goals
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

What Kind of Coding Program is Right for You?

There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.

  • 6
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now