On 1/20/18 3:42 PM, Alan Bartlett wrote: > On 19 January 2018 at 22:32, Bruce Ferrell <[log in to unmask]> wrote: >> >> On 1/19/18 12:41 PM, Akemi Yagi wrote: >> >> On Fri, Jan 19, 2018 at 10:31 AM, Bruce Ferrell <[log in to unmask]> >> wrote: >> >> On 1/18/18 3:51 PM, Bruce Ferrell wrote: >> On 01/18/2018 05:58 AM, Mark Stodola wrote: >> >> I just checked a vanilla kernel source tree against the kernel source rpm... >> ./drivers/usb/gadget is empty in the rpm version! >> >> What's up with that? >> >> usb-gadget is not supported upstream by TUV >> >> You could try the alternate kernels from ELrepo perhaps. >> -Mark >> >> Next on my agenda... I was just startled to see part of the source tree >> stripped out. >> >> ...And I find what looked like was stripped out is an artifact of not having >> the module enabled >> >> That's what I get for not building kernels since to early 2000s >> >> All of that aside, were one to WANT to rebuild the kernel, how would one go >> about that? >> >> As suggested by Mark, you can try ELRepo's kernel-ml or kernel-lt. In >> both kernels, gadget is enabled in the config: >> >> CONFIG_USB_GADGET=m >> >> If you wish to build your own kernel, then try following the instructions >> in: >> >> https://wiki.centos.org/HowTos/Custom_Kernel >> >> Or you could build just a module instead of a whole kernel: >> >> https://wiki.centos.org/HowTos/BuildingKernelModules >> >> Akemi >> >> Hi Akemi >> >> Yep, did all of those... Interesting rat hole(s) and good information. >> Turns out I don't need g_ether on the Scientific Linux side. >> >> it *looks* like a hotplug event is supposed to load a driver to create and >> interface usb0. More digging is required. >> >> Thanks for your attention! >> >> BTW, if someone knows the module that's supposed to load... It'd save me >> some time, but I can dig more too. >> > I'll suggest that you try something like the following -- > > $ lsusb > unconnected.txt > Plug in the device. > $ lsusb > connected.txt > $ diff unconnected.txt connected.txt > > -- and then report the hexadecimal ID pairing. From that, we might be > able to deduce the required driver. > > Here's my real-life example -- > > [Duo2 tmp]$ lsusb > unconnected.txt > [Duo2 tmp]$ # Plugged in the device. > [Duo2 tmp]$ lsusb > connected.txt > [Duo2 tmp]$ diff connected.txt unconnected.txt > 1d0 > < Bus 002 Device 002: ID 0b95:7720 ASIX Electronics Corp. AX88772 > [Duo2 tmp]$ > > -- the hexadecimal ID pairing for my example being 0b95:7720. That ID > pairing points to the asix driver. > > Alan. Thanks loads Alan, The "gadget" I'm plugging is, is a Raspberry PI and I found that the Scientific side is doing the right thing. ifconfig usb0 shows the usb network interface appears as it's supposed to. udev works! I stupidly thought I had to load g_ether on the "host" side. No... Not really. Just on the PI and that works out of the box. We can all go back to sleep now. I've been down the rabbit hole, learned how to build a modified kernel, found out that wasn't what I needed after all and returned to what I started out to do... a PI cluster using USB networking.