Surface Pro 4 registration issues

[Sebastian Roth]

@Avaryan thanks for that. I somehow had the feeling that it could be adapter related.

Maybe this is too far off but possibly we can help make it work with this adapter too. We got as far as linux kernel trying to bring up the interface. So the first couple of hurdles were left behind already.

Can you please boot up a linux live CD or USB key, maybe ubuntu. Boot up and open a terminal window. There you run the following commands:

dmesg | grep eth
lsusb
ip addr show

Take a picture of all the outputs you see on screen and post here.

[Avaryan]

Had a Raspberry Pi next to me, so that’s what I used.

[Sebastian Roth]

@avaryan said in Surface Pro 4 registration issues:

Had a Raspberry Pi next to me, so that’s what I used.

You mean you connected the USB NIC to the raspberry?! Though this is a good idea to get the information it’s not the same as booting a linux live system on the surface to see if it works properly. My fault I didn’t explicitely say that I wanted to test this as well - see if a linux live system booting on that surface device can bring up the NIC properly.

So back to the pictures you posted. Thanks for that! To me it looks as if you’ve connected two differnet USB NICs at the same time. Both are detected but getting no link. Where they hooked up to the network? Do both USB NICs fail with FOG at the very same step? I’d guess it’s better to focus on one of the NICs to not mix things up too much.

[Avaryan]

@sebastian-roth said in Surface Pro 4 registration issues:

@avaryan said in Surface Pro 4 registration issues:

Had a Raspberry Pi next to me, so that’s what I used.

You mean you connected the USB NIC to the raspberry?! Though this is a good idea to get the information it’s not the same as booting a linux live system on the surface to see if it works properly. My fault I didn’t explicitely say that I wanted to test this as well - see if a linux live system booting on that surface device can bring up the NIC properly.

So back to the pictures you posted. Thanks for that! To me it looks as if you’ve connected two differnet USB NICs at the same time. Both are detected but getting no link. Where they hooked up to the network? Do both USB NICs fail with FOG at the very same step? I’d guess it’s better to focus on one of the NICs to not mix things up too much.

There was only one USB NIC attached to the Raspberry Pi in these pictures. It was not connected to the internet.

I’ll have to download a live cd before I can test on the surface.

[Avaryan]

@Sebastian-Roth
Here is the output from the Surface device running Ubuntu 16.04 live CD. The Microsoft model 1821 dongle is being used to connect to the Internet.

ubuntu@ubuntu:~$ dmesg | grep eth
[    0.154336] ACPI Error: Method parse/execution failed [\_SB.PCI0.UA02] (Node ffff9112e68e3e60), AE_NOT_FOUND (20160930/psparse-543)
[   35.131648] cdc_ether 2-1.3:2.0 eth0: register 'cdc_ether' at usb-0000:00:14.0-1.3, CDC Ethernet Device, 94:9a:a9:86:4a:8f
[   35.132021] usbcore: registered new interface driver cdc_ether
[   35.136674] cdc_ether 2-1.3:2.0 enx949aa9864a8f: renamed from eth0
[   35.154528] cdc_ether 2-1.3:2.0 enx949aa9864a8f: kevent 12 may have been dropped
[   35.154534] cdc_ether 2-1.3:2.0 enx949aa9864a8f: kevent 12 may have been dropped
[   35.158223] cdc_ether 2-1.3:2.0 enx949aa9864a8f: kevent 12 may have been dropped
[   35.160373] cdc_ether 2-1.3:2.0 enx949aa9864a8f: kevent 12 may have been dropped
[   35.181749] cdc_ether 2-1.3:2.0 enx949aa9864a8f: kevent 12 may have been dropped
[   99.544696] cdc_ether 2-1.3:2.0 enx949aa9864a8f: kevent 12 may have been dropped
[   99.544714] cdc_ether 2-1.3:2.0 enx949aa9864a8f: kevent 12 may have been dropped
ubuntu@ubuntu:~$ lsusb
Bus 002 Device 004: ID 045e:0927 Microsoft Corp. 
Bus 002 Device 003: ID 2109:0812 VIA Labs, Inc. VL812 Hub
Bus 002 Device 002: ID 2109:0812 VIA Labs, Inc. VL812 Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 1286:204c Marvell Semiconductor, Inc. 
Bus 001 Device 005: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 004: ID 6557:0122  
Bus 001 Device 003: ID 2109:2812 VIA Labs, Inc. VL812 Hub
Bus 001 Device 002: ID 2109:2812 VIA Labs, Inc. VL812 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ubuntu@ubuntu:~$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether bc:83:85:2d:ae:b2 brd ff:ff:ff:ff:ff:ff
3: enx949aa9864a8f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 94:9a:a9:86:4a:8f brd ff:ff:ff:ff:ff:ff
    inet 10.20.20.191/16 brd 10.20.255.255 scope global dynamic enx949aa9864a8f
       valid_lft 691071sec preferred_lft 691071sec
    inet6 fe80::3af8:8518:3f25:a167/64 scope link 
       valid_lft forever preferred_lft forever

Dongle is going through a powered USB hub, due to the Surface only having 1 USB port.

[jwalt]

I just purchased the Surface dongle model 1663. I will try again with that and get back with the results.

[Sebastian Roth]

@Avaryan Ok, possibly we just need to add this model’s USB ID to the kernel source code.

@Tom-Elliott Would you please add ID 045e:0927 to drivers/net/usb/r8152.c. With a bit of luck this will make it work.

[Avaryan]

@sebastian-roth said in Surface Pro 4 registration issues:

@Avaryan Ok, possibly we just need to add this model’s USB ID to the kernel source code.

@Tom-Elliott Would you please add ID 045e:0927 to drivers/net/usb/r8152.c. With a bit of luck this will make it work.

@Sebastian-Roth @tom-elliott
Was this done? I’d be glad to test again. I only have one Surface device left and not sure how much longer I’ll have access to it.

[jwalt]

I was able to get the Surface Pro 4 to register with the 1663 Model dongle. I can test the new version after the driver has been added.

Thank you for all the help and quick response.

[Sebastian Roth]

@avaryan Kernel is being build right now. Will update this post in an hour when it’s done and uploaded.

[Tom Elliott]

Kernel 4.13.4 has been updated to include the 0927 identifier. Please update to working branch which will enforce your kernels to update to the latest on our site. Or you can do:

wget -O /var/www/fog/service/ipxe/bzImage https://fogproject.org/kernels/bzImage
wget -O /var/www/fog/service/ipxe/bzImage32 https://fogproject.org/kernels/bzImage32

Then test and let us know if it’s working for you please?

[Avaryan]

@tom-elliott I made the changes using the two wget’s you provided.

Test server is currently on 1.5.0-RC-9, SVN 6080.

It went further than before, but though up an error screen. I took pictures. Will attach soon.

[Avaryan]

Pulled latest working branch. Took me down to Version 65, SVN 6079. Re-tested. Same results.

[Sebastian Roth]

@Avaryan Well it looks like this got us past the DHCP issue of the inital posting. So adding that ID to the kernel source code does seem to help.

Please check your apache error log right after you see this error on screen. See my signature on where to find the log on your FOG server.