D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] Getting a USB AC68 dongle to work in Mint 19.3

 

On 08/04/2020 20:14, comrade meowski wrote:
On 07/04/2020 22:25, Julian Hall wrote:

I suspect the fly in the ointment is that last line ending 'added'.


Believe it or not I mostly agree with you - that's not quite right and it clashes with the correctly DKMS built 8812au modules listed above. I've seen that type of "added" message before when getting the DKMS status on systems where something has gone subtly wrong but am not immediately sure quite what. We do need to eliminate it though - this is exactly the sort of artefact I was worrying about when I asked you previously to clear up all previous experiments and messes so we could start clean. This one obviously snuck past you...

Actually I'm not so sure now I think about it - that line just means that it was added previously but is not currently in use(??). Let's just try and purge it anyway. Try:

sudo dkms remove -m rtl8814AU/4.3.21 --all

That might not be quite right so if it doesn't parse try tab completion (another sticky point on your system somehow...) for the "rtl..." part and the "4.3.21" part: both should autocomplete fine on a sane system.
(base) julian@CERCE:~$ sudo dkms remove -m rtl8814AU/4.3.21 --all
[sudo] password for julian:

------------------------------
Deleting module version: 4.3.21
completely from the DKMS tree.
------------------------------
Done.


Let's try and solve your weird bash completion issue as well:

sudo apt install apt-file
sudo apt-file update
Rebooting now.
Reboot once you've DKMS purged that rogue rtl8814AU instance and updated the apt-file cache. Then check the usual suspects:
[continuing reply after reboot]
* sudo dkms status
(base) julian@CERCE:~$ sudo dkms status
[sudo] password for julian:
8812au, 4.2.2, 4.15.0-96-generic, x86_64: installed
8812au, 4.2.2, 5.3.0-45-generic, x86_64: installed
8812au, 4.2.2, 5.3.0-46-generic, x86_64: installed
nvidia, 435.21, 4.15.0-96-generic, x86_64: installed
nvidia, 435.21, 5.3.0-45-generic, x86_64: installed
nvidia, 435.21, 5.3.0-46-generic, x86_64: installed

* lsmod | egrep -i 'rtl|881'
(base) julian@CERCE:~$ lsmod | egrep -i 'rtl|881'
8812au                987136  0

See if you can autocomplete some random kernels "sudo apt install linux-image- TAB TAB" and some other stuff, hopefully that'll work by now as well.
Still not working, as in I pasted the above line sans 'TAB' and tabbing did nothing.
Then if all looks good driver-wise and the correct module has been loaded, "dmesg -wT" and plug it in.
[Wed Apr  8 21:38:06 2020] usb 1-1.4: new high-speed USB device number 6 using ehci-pci [Wed Apr  8 21:38:06 2020] usb 1-1.4: New USB device found, idVendor=0b05, idProduct=1853, bcdDevice= 0.00 [Wed Apr  8 21:38:06 2020] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Wed Apr  8 21:38:06 2020] usb 1-1.4: Product: 802.11ac NIC
[Wed Apr  8 21:38:06 2020] usb 1-1.4: Manufacturer: Realtek
[Wed Apr  8 21:38:06 2020] usb 1-1.4: SerialNumber: 123456

No module bound to it by the looks of it at this point.

After this it gets tricky. I'd be inclined to report a bug to the github issues tracker for the project, it's pretty active. I've already had a browse through the bugs there and your system still doesn't look right compared to others - the "SerialNumber: 123456" and the device plumbing in but not getting a designation are both issues that have come up before for people and are a sure sign it's not working. Does the light come on by the way when you plug it in?
I was not aware there was a light, which probably answers that question.
Reading the bug reports it looks as if it should come on bright blue when fully activated.

If you're up to it then personally I'd do all the usual sysadmin tests: swap it between USB ports, sanity check it in a couple of different computers with different operating systems, etc.
Would it work - if it's going to - in a Live distro? I have three to try.
All time consuming but if you want to fix it properly then tough luck I'm afraid! I'd also switch it to a different Mint box (which I know you have to hand) and now you know what you're doing, redo the driver DKMS install from scratch on a clean system to see how that goes.
That would be my laptop, a Lenovo x201 - also Mint 19.3. Given that I do have a Raspberry Pi v2 and the driver disk does have /those/ drivers on it, would it be worth trying that?

After _that_ it's file a bug report and wait for the dev to come back I'm afraid. Welcome to Linux!

Tip for the future - I expect you've had this older wifi adaptor lying around for a while so it's a sunk cost, no problem.
No, bought last week.. I made the mistake of seeing it said it works on a Raspberry Pi and - as Raspbian is Debian based as is Mint - I thought it would be OK. No.. not so much..
When buying wifi anythings in the future that are destined for a Linux system don't bother looking up the usual driver support matrices, instead research what chipsets/models the evil hackers are using for their packet injection shenanigans. If a wifi adaptor is not just linux supported but also has solid recommendations online for use in airmon-ng etc and is known good for supporting packet injection then it's a keeper. Pay over and above the normal prices for a unit like that and you won't have to put up with this crap in the future. In the old days that meant _always_ buying certain Atheros chipset units but there are a lot of options now. Remember, no packet injection support = no buying for linux boxes.

Duly noted.

Kind regards,

Julian

--
“The great tragedy of Science — the slaying of a beautiful hypothesis by an ugly 
fact.”

― Thomas Henry Huxley


--
The Mailing List for the Devon & Cornwall LUG
https://mailman.dcglug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq