[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 06/04/20 20:29, Julian Hall wrote: > On 06/04/2020 16:41, Julian Hall wrote: >> On 05/04/2020 23:40, comrade meowski wrote: >>> On 05/04/2020 23:29, Michael Everitt wrote: >>> >>>>>> (base) julian@CERCE:~$ lsmod | grep 8812au >>>>>> 8812au 987136 0 >>>>>> >>>>>> It seems to be loaded. >>>>>> >>>>>> BTW I also downloaded Live ISOs of Debian, OpenSuse and Fedora. >>>>>> Would it >>>>>> be worth longterm seeing if they behave better? >>>>>> >>>>> Ah! I've just spotted a problem, it's 8814au not 8812au. Apologies if I >>>>> said it was an 8812au. Updated lsmod output: >>>>> >>>>> base) julian@CERCE:~$ sudo modprobe 8814au >>>>> [sudo] password for julian: >>>>> modprobe: FATAL: Module 8814au not found in directory >>>>> /lib/modules/5.3.0-45-generic >>>>> >>>>> It looks like it's not loaded which explains a lot. >>>>> >>>> No, no, that's the correct driver for the 8814 chipset .. the 8812au >>>> covers >>>> both types. >>>> >>>> what do you get now with 'ifconfig -a' .. you should have something that >>>> starts 'wl.....'. Failing that, 'dmesg | grep 8812' might tell us >>>> something ... >>> >>> >>> More specifically, in a terminal run: >>> >>> dmesg -wT >>> >>> And then watch it live update as you unplug/replug the adaptor. dmesg >>> will spit out kernel messages which will tell you what's happening. >>> ME's right about the driver as well so don't worry about that - it's >>> also autoloading correctly so you're 90% of the way there. >>> >>> We just need to get it under the control of your chosen GUI network >>> manager now so you can use it without having to ifconfig it up. >>> >> Many thanks Michael and Mr Meowski :) >> >> (base) julian@CERCE:~$ ifconfig -a >> enp0s10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 >> inet 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255 >> inet6 fe80::1110:fb2e:baa6:2ceb prefixlen 64 scopeid 0x20<link> >> ether 00:19:66:f7:4b:1c txqueuelen 1000 (Ethernet) >> RX packets 100958 bytes 87817528 (87.8 MB) >> RX errors 1 dropped 0 overruns 1 frame 0 >> TX packets 61437 bytes 10249154 (10.2 MB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >> >> lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 >> inet 127.0.0.1 netmask 255.0.0.0 >> inet6 ::1 prefixlen 128 scopeid 0x10<host> >> loop txqueuelen 1000 (Local Loopback) >> RX packets 12760 bytes 1179933 (1.1 MB) >> RX errors 0 dropped 0 overruns 0 frame 0 >> TX packets 12760 bytes 1179933 (1.1 MB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >> >> Nothing from wlan0 or whatever Mint has called it. >> >> dmesg -wT output: >> >> [Mon Apr 6 15:44:53 2020] usb 1-1.4: USB disconnect, device number 4 >> [Unplugged it and got this] >> [Mon Apr 6 15:45:03 2020] usb 1-1.4: new high-speed USB device number 5 >> using ehci-pci [plugged back in and got this] >> [Mon Apr 6 15:45:03 2020] usb 1-1.4: New USB device found, >> idVendor=0b05, idProduct=1853, bcdDevice= 0.00 >> [Mon Apr 6 15:45:03 2020] usb 1-1.4: New USB device strings: Mfr=1, >> Product=2, SerialNumber=3 >> [Mon Apr 6 15:45:03 2020] usb 1-1.4: Product: 802.11ac NIC >> [Mon Apr 6 15:45:03 2020] usb 1-1.4: Manufacturer: Realtek >> [Mon Apr 6 15:45:03 2020] usb 1-1.4: SerialNumber: 123456 [this >> genuinely is the serial number] >> [Mon Apr 6 15:46:15 2020] usb 1-1.4: USB disconnect, device number 5 >> [Mon Apr 6 15:46:25 2020] usb 1-1.4: new high-speed USB device number 6 >> using ehci-pci >> [Mon Apr 6 15:46:25 2020] usb 1-1.4: New USB device found, >> idVendor=0b05, idProduct=1853, bcdDevice= 0.00 >> [Mon Apr 6 15:46:25 2020] usb 1-1.4: New USB device strings: Mfr=1, >> Product=2, SerialNumber=3 >> [Mon Apr 6 15:46:25 2020] usb 1-1.4: Product: 802.11ac NIC >> [Mon Apr 6 15:46:25 2020] usb 1-1.4: Manufacturer: Realtek >> [Mon Apr 6 15:46:25 2020] usb 1-1.4: SerialNumber: 123456 >> >> I also tried with the device out of the cradle supplied with it. As >> expected the output was identical as it's essentially just a fancy USB >> port on the end of a metre lead. >> >> It seems then the system recognises it being plugged in, and identifies >> it correctly. It just won't use the driver to load it. >> >> This appears to be /why/.. >> >> (base) julian@CERCE:~$ dmesg | grep 8812au >> [ 6.474688] 8812au: loading out-of-tree module taints kernel. >> [ 6.476208] 8812au: module verification failed: signature and/or >> required key missing - tainting kernel >> [ 6.477961] usbcore: registered new interface driver rtl8812au >> (base) julian@CERCE:~$ >> >> I'm guessing that means the kernel doesn't like it so won't allow >> anything to use it? >> >> Kind regards, >> >> Julian > > Hmm.. Mint wanted to update the kernel and headers etc to > 4.15.0-96-generic, and seemed to do it, but I spotted this in the middle.. > > Processing triggers for linux-image-4.15.0-96-generic (4.15.0-96.97) ... > /etc/kernel/postinst.d/dkms: > * dkms: running auto installation service for kernel 4.15.0-96-generic > > Kernel preparation unnecessary for this kernel. Skipping... > > Building module: > cleaning build area... > 'make'....(bad exit status: 2) > Error! Bad return status for module build on kernel: 4.15.0-96-generic > (x86_64) > Consult /var/lib/dkms/rtl8814AU/4.3.21/build/make.log for more information. > ...done. > > This is what make.log said: > > cc1: some warnings being treated as errors > scripts/Makefile.build:288: recipe for target > '/var/lib/dkms/rtl8814AU/4.3.21/build/core/rtw_cmd.o' failed > make[2]: *** [/var/lib/dkms/rtl8814AU/4.3.21/build/core/rtw_cmd.o] Error 1 > Makefile:1655: recipe for target > '_module_/var/lib/dkms/rtl8814AU/4.3.21/build' failed > make[1]: *** [_module_/var/lib/dkms/rtl8814AU/4.3.21/build] Error 2 > make[1]: Leaving directory '/usr/src/linux-headers-5.3.0-45-generic' > Makefile:1699: recipe for target 'modules' failed > make: *** [modules] Error 2 > > Kind regards, > > Julian > > Wow, sounds like you're having a time of it .. but on the right rough course .. meowski might be able to point out any pitfalls! Best regards, Michael.
Attachment:
signature.asc
Description: OpenPGP digital signature
-- The Mailing List for the Devon & Cornwall LUG https://mailman.dcglug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq