Surface Pro 3 - ipxe issues

[xerxes2985]

0_1479320050891_test.pcap

@george1421

here’s a wireshark capture I did of any traffic going into FOG

[xerxes2985]

@george1421

Now that I figured out how to take it out of my Ubuntu server, here is the file.
0_1479321004153_output.pcap

[george1421]

I’m IM’ing with you but its pretty lonely when you don’t respond.

Here is the relevant information from the pcap file. Its packet #7.

We can see that this device has a unique UUID which is cool we can use that if we want to create a custom dnsmasq filter.
We also can see that the system arch is type 7 EFI BC. That info will be used in the ltsp.conf file. According to your posted config file dnsmasq should send ipxe.efi for the type BC_EFI.

[george1421]

I had a quick IM session with the OP. He was able to get the surface pro to boot using the ipxe7156.efi file. He went the bit longer way the wiki defined to get to the right answer. But this route would have worked too. (the longer way is the proper way if you need to add filters some time in the future).

<edit> the OP IM’d me and said that this route did not work as expected so he went the longer route. Do no follow this section since it is now suspect.
In his posted ltsp.conf file, if he would have replaced

pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi

with

pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe7156.efi

it would have worked equally as well.

But this way unfortunate all Arch 7 type devices would get the same ipxe boot file. With filters you can tailor the boot file based on the specific booting client type (assuming that the vendor set the uuid field correctly)

[xerxes2985]

All,

I’ve modified my itsp.conf to the following based upon ProxyDHCP_with_dnsmasq:Adding (a bit more complex) UEFI support to the basic script

port=0
log-dhcp
tftp-root=/tftpboot
dhcp-no-override

dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,x.x.x.x
dhcp-boot=net:UEFI,ipxe7156.efi,,x.x.x.x
dhcp-boot=net:UEFI64,ipxe.efi,,x.x.x.x
dhcp-boot=undionly.kpxe,,x.x.x.x
pxe-prompt="Booting FOG Client", 20

dhcp-range=x.x.x.x,proxy

The key to getting the Surface Pro 3 to PXE boot into the FOG Menu, and successfully start a Full Registration was modifying the following values.

dhcp-boot=net:UEFI,ipxe.efi,,x.x.x.x

To This

dhcp-boot=net:UEFI,ipxe7156.efi,,x.x.x.x

I am currently 12% of the way through capturing an image, although my VM will probably fill up.

[george1421]

@xerxes2985 You have the proper setup now. Adding filters (if you need them) is just a short walk from there. There is two ways you can go with the config file, easy and a little harder. But the little harder gives you many more options.

The wiki page you referenced is based on my working document here: https://forums.fogproject.org/topic/8726/advanced-dnsmasq-techniques

which goes into the details a bit more.

[Tom Elliott]

@xerxes2985 is it possible it’s looping back because it’s looking for snponly.efi.0?

[Wayne Workman]

@george1421

PXEClient:Arch:00007:UNDI:003016

Either one of two things here…

Either this is not a Surface 3 but is actually a Surface 4, or, all Surface Pros have the exact same vendor class identifier.

Why do I say this? That vendor class identifier is exactly what we found for a Surface Pro 4 and integrated into FOG’s built-in DHCP configuration:
https://github.com/FOGProject/fogproject/blob/dev-branch/lib/common/functions.sh#L2020

[Tom Elliott]

@Wayne-Workman I only say that because he’s using Dnsmasq (.0). I’m not sure if Dnsmasq still looks for .0 regardless of what the filename actually is.

[Wayne Workman]

@Tom-Elliott Simon Kelly did away with the .0 thing in the version we instruct people to build I believe, mostly because it made .0 sense

[Tom Elliott]

So now that you have a working system, is it safe to solve this thread?

[george1421]

@Wayne-Workman said in Surface Pro 3 - ipxe issues:

PXEClient:Arch:00007:UNDI:003016

This really doesn’t tell you anything useful in regards to uniqueness.
There is actually 4 parts there in that option 60 value. Those values are also present in other dhcp options like 93, 94, and I think 97 (as said from a faulty memory).
the undi part on the end is the undi version 003 and I forget what the 016 is but its not unique. But in the case of this surface pro the uuid file is unique. That just needs to have a filter created for the uuid part and to exclude the sid part.

[Wayne Workman]

@george1421 the UUID is unique per device though. We were trying to find something unique to the surface pro because FOG’s latest boot files won’t work with them for whatever reason, and none of us have a Surface Pro to even begin to figure out what’s wrong.

[george1421]

@Wayne-Workman The issue/trouble is the UUID entry is up to the device manufacturer to populate. Dell does it, Microsoft must do it, Lenovo and ASUS not so much (at least with the testing I’ve see so far).

In the case of the dells there are two parts to the UUID the system ID that identifies the hardware and the right part that is the mac address of the computer (computer unique part). For the surface pro it doesn’t look like MS followed that when creating the UUID. What we would need to do is capture 2 discover packets from two different surface pros of the same model and compare the uuid part to see where the unique system ID is. I would expect the left part of the UUID to be system model consistent and the right part to be device unique part. But I’m only guessing here. MS may have done something totally different.

That is why we need the support of the people who have surface pros to collect this data for use so we can make the FOG system even better that it is today. As I posted before I’m sure the developers would gladly accept a donated surface pro 4 to help clean up a bit of theses still unknowns.

[Scott Adams]

@george1421 I will work on getting something together and post it once complete.

In the meantime, I use Windows DHCP service (not FOG’s DHCP). I simply set my 66 and 67 scope options to my fog server and to snponly.efi ( I still have to manually change this setting as my DHCP server is 2008).

I use the actual Microsoft Surface USB Ethernet adapter. I used to have to add has_usb_nic=1, but that was not needed after a particular RC (I can’t remember which one).

Also as part of the imaging, I do have an issue with using the Type Cover. I can use it in the FOG menu, but when it wants me to disconnect the NIC, plug it back in, and hit Enter, it will not recognize any input from the Type Cover. I simple plug in a USB keyboard, hit enter, then plug my Ethernet adapter back in.

[xerxes2985]

@Tom-Elliott @george1421 @Wayne-Workman @Scott-Adams

First, I can assure you its a Surface Pro 3. Unfortunately, its the only one I have at the moment so I cannot verify whether multiple SP3 share the same vendor class. (although I am guessing they may)

PXEClient:Arch:00007:UNDI:003016

The other question in regards to changing to snponly.efi, it could have been I wasn’t pointing the BC_EFI entry.

Correct entry

pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe7156.efi

Wrong architecture entry

pxe-service=X86-64_EFI, "Boot Surface UEFI" snponly.efi

Tom, to answer your question, yes I believe you can mark this as solved.

Thanks for all your help.

[george1421]

@xerxes2985 just for reference I’ve started documenting this solution here: https://forums.fogproject.org/topic/8971/pxe-booting-surface-pro-3-to-fog-menu