[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 06/04/2020 21:24, Michael Everitt wrote:
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, JulianHmm.. 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, JulianWow, 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.
Thanks Michael.It looks as if somehow amid the carnage I managed to get an 8814au driver from somewhere. Could the 8812au and 8814au be conflicting, both trying to use the same device? 8814au binds to it, kernel doesn't like it so 8814au cannot run, but because it has already bound to the device 8812au which the kernel would accept is unable to do so. It's my logic, and may be total codswallop, but if correct can I get rid of the 8814au and see then if the 8812au will behave, or should I try to get the kernel to accept the 8814au?
Incidentally, on the /Windows/ installation CD I found a folder called Linux! However it appears to have Raspberry Pi drivers in it so I am very loathe to mess the situation up even further by trying them.
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