Surface Pro 4 registration issues
-
Had a Raspberry Pi next to me, so that’s what I used.
-
@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.
-
@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.
-
@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.
-
I just purchased the Surface dongle model 1663. I will try again with that and get back with the results.
-
@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 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. -
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.
-
@avaryan Kernel is being build right now. Will update this post in an hour when it’s done and uploaded.
-
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?
-
@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.
-
Pulled latest working branch. Took me down to Version 65, SVN 6079. Re-tested. Same results.
-
@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.