I'm interested in having an Orange Pi act as a VNC host to various platforms having the ethernet running over the OTG cable. To that end I've been testing the Armbian Debian_stretch_next desktop image with the 4.x kernel (dated 5.34.171129 nightly build) on my Orange Pi Pc+. I placed g_ether in the /etc/modules and configured it with the module parameter
options g_ether use_eem=1
in my g_ether.conf file in /etc/modprobe.d and
allow-hotplug usb0
iface usb0 inet static
address 169.254.1.1
netmask 255.255.0.0
in my /etc/network/interfaces file. I have set up the orange pi to run a DHCP server and avahi on the OTG (usb0) port as well. With the eem parameter and this setup Windows 7, 8, and 10 will automatically detect my orange pi over the usb-otg cable, load a driver and setup the network for it. In Windows 8 and 10 even zeroconf seems to work and I can identify the orange pi with a name. This configuration works in Windows whether I first power up the pi and then connect it or if I have it already connected when I power up the orange pi.
When I use my Linux host (running Linux Mint 18 Sarah) to connect to the orange pi the setup will also automatically work if I have the orange pi pc+ already booted and then connect the USB cable to the host. However if I have the USB-OTG cable already connected and then power up the orange pi the connection fails to activate correctly, even if I remove it and plug it in again. I have tried switching the Linux host to Link-Local only instead of using DHCP but this still does not work in this scenario. Typically the Linux Host complains with repeated errors in dmesg of
cdc_eem 2-1:1.0 enp0s20u1: kevent 12 may have been dropped
On the orange pi, however the log suggests that g_ether is ready and the module appears to be loaded though it clearly isn' t working.
This seems to be a minor issue as on the orange pi pc+ as I could just wait for it to boot and then plug it into the Linux host but I am anticipating ultimately using this with an Orange Pi zero plus 2 (on order) where both the power and this network connection would presumably run over the same USB-OTG cable (assuming that is possible).
So I'd be curious if anyone is able to boot their orange pi pc + and have the g_ether work properly with a Linux host when the cable is already connected at boot. If I want to have the Orange Pi work cross platform it should work with Linux as well as the others. Incidentally I tried using the g_cdc module and that does work with the Linux host when the orange pi is booted already connected. However g_cdc is problematic for Windows because it defaults to thinking of the device as a serial connector. I want something that can work out of the box as one of my use cases would typically be students so using g_ether would seem desirable. I have looked around the web and these forums for a solution but did not see one.
Any help is much appreciated. If this has been fixed since my last download of the nightly build I apologize. I did want to mention the module parameter use-eem as others might find the info useful in any event when connecting to Windows boxes.
Thanks!
I'm interested in having an Orange Pi act as a VNC host to various platforms having the ethernet running over the OTG cable. To that end I've been testing the Armbian Debian_stretch_next desktop image with the 4.x kernel (dated 5.34.171129 nightly build) on my Orange Pi Pc+. I placed g_ether in the /etc/modules and configured it with the module parameter options g_ether use_eem=1 in my g_ether.conf file in /etc/modprobe.d and allow-hotplug usb0 iface usb0 inet static address 169.254.1.1 netmask 255.255.0.0 in my /etc/network/interfaces file. I have set up the orange pi to run a DHCP server and avahi on the OTG (usb0) port as well. With the eem parameter and this setup Windows 7, 8, and 10 will automatically detect my orange pi over the usb-otg cable, load a driver and setup the network for it. In Windows 8 and 10 even zeroconf seems to work and I can identify the orange pi with a name. This configuration works in Windows whether I first power up the pi and then connect it or if I have it already connected when I power up the orange pi. When I use my Linux host (running Linux Mint 18 Sarah) to connect to the orange pi the setup will also automatically work if I have the orange pi pc+ already booted and then connect the USB cable to the host. However if I have the USB-OTG cable already connected and then power up the orange pi the connection fails to activate correctly, even if I remove it and plug it in again. I have tried switching the Linux host to Link-Local only instead of using DHCP but this still does not work in this scenario. Typically the Linux Host complains with repeated errors in dmesg of cdc_eem 2-1:1.0 enp0s20u1: kevent 12 may have been dropped On the orange pi, however the log suggests that g_ether is ready and the module appears to be loaded though it clearly isn' t working. This seems to be a minor issue as on the orange pi pc+ as I could just wait for it to boot and then plug it into the Linux host but I am anticipating ultimately using this with an Orange Pi zero plus 2 (on order) where both the power and this network connection would presumably run over the same USB-OTG cable (assuming that is possible). So I'd be curious if anyone is able to boot their orange pi pc + and have the g_ether work properly with a Linux host when the cable is already connected at boot. If I want to have the Orange Pi work cross platform it should work with Linux as well as the others. Incidentally I tried using the g_cdc module and that does work with the Linux host when the orange pi is booted already connected. However g_cdc is problematic for Windows because it defaults to thinking of the device as a serial connector. I want something that can work out of the box as one of my use cases would typically be students so using g_ether would seem desirable. I have looked around the web and these forums for a solution but did not see one. Any help is much appreciated. If this has been fixed since my last download of the nightly build I apologize. I did want to mention the module parameter use-eem as others might find the info useful in any event when connecting to Windows boxes. Thanks!