[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
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:No, no, that's the correct driver for the 8814 chipset .. the 8812au coversAh! I've just spotted a problem, it's 8814au not 8812au. Apologies if I(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 itbe worth longterm seeing if they behave better?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.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 -wTAnd 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: 123456I 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 errorsscripts/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 1Makefile: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 -- The Mailing List for the Devon & Cornwall LUG https://mailman.dcglug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq