Microsoft Surface Pro 4 (using dock) has Issues with DHCP for Imaging Task

[Tom Elliott]

Is it possible your dhcp server has run out of leases? What I mean is as the device connects dhcp is requested at least three times. It looks like pxe and ipxe work fine, but the reason inits fail, even manually attempting, is it just isn’t getting an answer back. I’m only guessing that it’s not responding back as the server has nothing to respond back with. Again this is just a guess. Particularly considering registration worked fine, which uses the same method to get dhcp as and other unit based tasking would.

[george1421]

This one seems very challenging. The iPXE kernel has command of this network interface but FOS (customized linux kernel) does not.

It would be interesting to see when you booted into debug (capture or deploy) as you have. Setup wireshark with the following capture filter port 67 or port 68 then issue the udhcpc command. Is anything coming from FOS for dhcp? What happens of you issue a udhcpc -i eth0 Is anything sent from target computer?

If you manually configure an IP address to FOS can you ping devices on your network?

If you review /var/log and I think it syslog (or messages) and look for the network interface coming up, is there any error message?

In doing a quick google-fu search, I see this IS an issue that has been reported with udhcpc so I don’t think its localized to FOG. There has to be a clue here. I have a surface book for one of our ViPs sitting on the bench I can test today to see if I get the same results.

[Dahrell]

@Tom-Elliott @george1421 Thank you guys for your responses! We have repair center PCs using FOG constantly and they obtain IPs flawlessly and works as intended it just seems that Surfaces want to be the problem child. I’ve attempted pings to the FOG server itself with the manual setup of IP and to no avail. I haven’t tried WireShark with those particular filters though I will definitely get on that and have that to you soon!

[Dahrell]

I ran the command again to capture for ya’ll to see with just the dock. The strange thing is that, in order to test a usb-to-ethernet adapter I had the dock (with the ethernet plugged into it) and the usb adapter connected and booted to PXE then it attempted to grab IP from DHCP as expected and failed again. However when debug reached the command line for the init.xz I moved the ethernet to the usb adapter and ran udhcpc on eth1 thinking that eth1 was the usb adapter (eth1 has the MAC of the dock which originally didn’t work). Upon running the command it worked as if the dock was using the adapter to communicate to the DHCP properly! But on boot the usb adapter doesn’t even attempt to PXE boot and I’ve tried to Alternative boot and to change the boot order, both of which don’t work. >.<

THE SOLUTION, however, was to have the dock to boot to PXE and a USB adapter plugged in at boot. Then when prompted to replug the usb, unplug the dock completely, then replug the USB adapter, move the ethernet cable to the USB adapter, hit ENTER to proceed. This makes me curious if the Microsoft Certified adapter will PXE boot like the dock and grab from DHCP without a hitch. If so I’m sorry I wasted ya’lls time. Why Microsoft… just… why?..

After Running udhcpc eth1 with the USB Adapter

After Running udhcpc eth0 (no USB Adapter)

Blank Conversation After (no USB Adapter)

[george1421]

@dahrell OK here is what I did.

I have a surface book pro 2 with the external dock. I have a FOS USB stick so I can boot into FOS (linux OS that runs on the target computer) without needing to PXE boot. I used this route since you already established that pxe booting working into iPXE kernel, but the issue was with FOS.

I can duplicate the same issue as you have with my hardware. FOS sees the network adapter but can not init it. I plan on debugging this during my lunch hour after I can figure out how to make the fonts bigger on the screen. Right now I would say they are about 3-4 points in size. Now that I can duplicate the issue, lets see what I can find.

FWIW: I updated my FOS USB with the latest FOG kernel 4.15.2 and the inits for 1.5.0.

[george1421]

@george1421 Well after some IT hokus-pokus (it magic). I was able to extract this info from the FOS logs.

Mar 20 11:04:27 fogclient user.info kernel: usbcore: registered new interface driver r8152
Mar 20 11:04:29 fogclient user.info kernel: r8152 2-4.2:1.0 eth0: v1.09.9
Mar 20 11:04:38 fogclient user.info kernel: r8152 2-4.2:1.0 eth0: carrier on
Mar 20 11:04:39 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:04:42 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:04:45 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:04:49 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:04:52 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:04:55 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:04:59 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:05:02 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:05:05 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71

Which correlates with this document: https://www.spinics.net/lists/netdev/msg463854.html So from the document it appears that something has changed in kernel 4.12 and newer. There was no joy in that thread because it appears to not have been answered.

Another thread I found:

Broke for me too on Ubuntu 16.04.3 LTS with new kernel 4.13. Still works with 4.10.

and

It works for me using Kernel 4.10, breaks in 4.13 RC6 and RC7

Lastly it appears to be still an ongoing issue:
https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1742922

Looks like the r8152 driver is working with the device that has the usb id: 0bda:0307, which is an usb 3.0 to ethernet adapter with three usb 3.0 ports on it.

The affected device where the driver is not working, has the usb id 045Ep:07C6d, which is in a docking station (2 x display port, 2 x usb 2.0, 2 x usb 3.0).

The MS Surface dock in my system is a 045e:07c6 (not sure where the OP of the above thread got the extra characters from, but it appears to be the same unit).

[Dahrell]

Haha, well I will either tomorrow or later this week see if the Microsoft USB Adapter works by itself. If not, it’s not a huge issue to use the dock for PXE booting and then switching over to a generic USB Adapter when prompted to accomplish the imaging.

Thank you for all ya’lls effort and time!

[Wayne Workman]

@george1421 Wouldn’t downgrading the kernel work in this case?

[Dahrell]

Yeah I can test if using 4.10 for the dock will work as well.

[Dahrell]

It still won’t get to PXE. I think any non-Microsoft USB peripherals or USB Bootable devices are being ignored on boot? Maybe the updated UEFI firmware has changed the behavior of what peripherals are usable at boot. Once I get to the section where it asks me to replug the generic USB adapter and I move the ethernet over to it, it works on 4.15.2. I tried Kernel Versions 4.10.1 and 4.10.10 with the dock and the adapter by itself but still no success.

[george1421]

@dahrell Sorry I’ve been looking at other issues.

I was able to get a generic USB ethernet adapter to work once FOS was booted. But that won’t help you since it will have another mac address. Using a down level kernel might work, you can assign that kernel to that specific bit of hardware via the host configuration page. I was just looking but I can’t seem to find old FOS kernels in the 4.10 era. I know they exist, I just can’t locate them at the moment. Plus there is no guaranty that they will include the driver for this bit-o-dock. The right solution is for the linux kernel developers to fix the code to support these things.

For you to use a third party network adapter to pxe boot, you may find no joy there either. The UEFI firmware has to have the drive built in to support pxe booting. I don’t suspect that M$ will include any drivers in the uefi firmware other than their own hardware.

Lastly you could always usb boot into FOS using the FOS USB stick. Its not an ideal situation, but it would bypass pxe booting by booting FOS off the usb stick (as I did in my testing). Then all you need to have is a FOS supported usb ethernet adapter to image.

[Dahrell]

Yeah they’re forcing only Microsoft PXE devices on Surfaces.

https://docs.microsoft.com/en-us/surface/ethernet-adapters-and-surface-device-deployment

"Booting from the network (PXE boot) is only supported when you use an Ethernet adapter or docking station from Microsoft. To boot from the network, the chipset in the Ethernet adapter or dock must be detected and configured as a boot device in the firmware of the Surface device. Microsoft Ethernet adapters, such as the Surface Ethernet Adapter and the Surface Dock use a chipset that is compatible with the Surface firmware.

The following Ethernet devices are supported for network boot with Surface devices:

Surface USB to Ethernet adapter

Surface USB 3.0 Ethernet adapter

Surface Dock

Surface 3 Docking Station

Surface Pro 3 Docking Station

Docking Station for Surface Pro and Surface Pro 2

Third-party Ethernet adapters are also supported for network deployment, although they do not support PXE boot."

[Wayne Workman]

@george1421 said in Microsoft Surface Pro 4 (using dock) has Issues with DHCP for Imaging Task:

The right solution is for the linux kernel developers to fix the code to support these things.

Or for Microsoft to make a pull request to the Linux kernel with the fixes for their hardware. That’d be the responsible thing to do on Microsoft’s part.

[george1421]

@wayne-workman said in Microsoft Surface Pro 4 (using dock) has Issues with DHCP for Imaging Task:

That’d be the responsible thing to do on Microsoft’s part.

[snark on] But why, there is no profit in that. Fixing linux does not push their crappy windows 10 agenda at all. [snark off]

[george1421]

FWIW: You can get older FOG Project created kernels from this URL: https://fogproject.org/kernels/

[Dahrell]

Verified today that it does indeed require the Microsoft Ethernet Adapter on Surface Pro 4 and that it works with a Kernel Argument of has_usb_nic = 1 and Host Kernel of bzImage version 4.13.4! You have to create a host in the FOG Web Interface with the MAC of the adapter. Make sure the dock is removed before booting. When it prompts to remove the usb and replug leave the adapter in. Do not remove and hit ENTER.

Thanks again for your help previously!

[m144]

@dahrell I know the pain!

The same thing happened to me when trying to use that docking station for the Surface Pro. The thing I don’t understand is that docking station will work for me when imaging a Surface Book but not a Surface Pro.

I ended up just using this surface docking station and it works every time with the newest kernel… Even tho it says it is for the Surface Pro 3 it did work with our 4’s.

Good luck,
-M144

[grenfell]

Hi.

I’ve also had problems doing “deploy” image to a Microsoft Surface Pro 4 however I accidentally stumbled upon a workaround of connecting two (2) network interfaces to the Surface Pro 4 as a solution. I connect the Surface Pro 4 to the “Dock” (part # PF3-00005) which is connected to our Ethernet LAN and I also plug a Surface Ethernet Network adapter (part # EJS-00002) into the Surface’s USB3 port. Yes, I know it is silly to connect two Ethernet interfaces to the surface however for whatever reason this allows the “Deploy” to work successfully.

HERE’S DETAILS ABOUT OUR ENVIRONMENT

FOG server version: 1.4.4 (note on 4/3/2018 I see that “Latest stable version is 1.5.0”)

I used the 'Windows 2012 R2" steps at https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy to configure our DHCP option “067 Bootfile Name” to ipxe7156.efi (not ipxe.efi)

After I unbox a new Surface Pro 4 I do the following …

1. Manually add a “hosts” record for the new Surface Pro 4 to FOG
   a. Open the box with the “Dock” and write down the Dock’s Ethernet MAC address (which is in very tiny light print)
   b. From FOG’s “Hosts” menu click “Create New Host”
   c. Fill in the following form options:
   i. “Host Name” = “pc_surface03” (or something suitable)
   ii. “Primary MAC” = whatever is written on the “Dock” (we assign one dock specifically to each surface because the DOC’s Ethernet MAC address is the key field for FOG host identification)
   iii. “Host Image” = select UEFI image form the list
   iv. “Host Kernel Arguments” = “has_usb_nic = 1”
   v. Scroll down and under the “Active Directory” section check the box for “Join domain after image task”
   vi. Scroll down to the bottom and click the “Add” button

2. Plug the Dock’s power brick into a wall outlet

3. Connect the Dock’s power brick to the dock

4. Connect an Ethernet cable to the Dock’s Ethernet port

5. Connect the Dock to the Surface Pro 4

6. Plug a Surface Ethernet Network adapter (part # EJS-00002) into the Surface’s USB3 port

7. Connect the Surface Ethernet Network adapter (part # EJS-00002) to our LAN

8. Now we PXE boot the Surface Pro 4 for the first time with the following steps:
   a. Hold in [volume-up] and tap the power button
   b. When “Surface” appears on the screen release [volume-up]
   c. Touch “Security” on the left
   d. In the “Secure Boot” touch “Change Configuration” button
   e. Touch “None” and then touch the “OK” button
   f. Touch “Boot Configuration” on the left
   g. Change “Enable IPv6 for PXE Network boot option” option to “Off”
   h. Drag the “PXE Network” item to the left
   i. When it asks “Boot this device immediately” touch “OK” button
   j. When the FOG menu appears you will see the heading “Host is registered as lap_surface03” (or whatever name you manually registered it as)

9. Now we deploy our image
   a. Choose “Deploy Image”
   b. Login to FOG
   c. Select the OOBE image you want to deploy
   d. Wait 2 minutes for the image to be deployed
   e. Even though the image was deployed successfully the deployment “task” remains running forever on the FOG server, so in your web browser (on another PC) navigate to FOG’s “Task Management” page, check the box next to the deployment task that has finished and click the “Cancel selected tasks?” button

I hope the above information is useful to someone else.

[x23piracy]

Hi,

for all the surface cramp i always used this one with success without any special settings:
https://www.amazon.com/Microsoft-3U4-00001-Surface-Ethernet-Adapter/dp/B00N3JHBFM
There is also another one, but i can just talk for the one with the skewed usb sheating. I don’t know if the other one has the same interiority:
https://www.amazon.com/Surface-USB-Gigabit-Ethernet-Adapter/dp/B06ZZNPHQX

Regards X23