Edimax Drivers

[Muredac Ford]

Howdo I install drivers for Edimax AC 600 Wi-Fi adapter drivers?

I went on their website and there are no drivers for the newer versions of the kernel 5.4.0

Is there a way to install generic drivers (currently I don't see the Wi-Fi/Wireless icon in network settings on Ubuntu).

edit: There is another set of repositories that provide drivers for many unsupported Realtek USB WiFi chips (including the rtl8812). I strongly recommend to use this solution from now on.morrownr repository

As best as I can tell from my reading and poking around the chipset RTL8812AU is supported from LibreElec 7.95.06 onward. Of course this includes Kodi Krypton which may break my builds and add-ons.

I've found a couple of links below that suggest a manual way of introducing support for a new WiFi dongle. Is it possible to use some similar method to provide support for this adapter on LibreElec 7.0.3? Or any version for that matter?

I will continue to search and research for a solution but perhaps someone with knowledge can let me know if my efforts may bare fruit or if I should go ahead and return to retailer for a refund and exchange for a more compatible [and slower] Wifi adapter which is my current plan.

We aren't fans of realtek drivers that sit outside the kernel because they are usually poor quality and problematic to maintain. It's probably not hard to build the driver, but it's debatable whether we really want more realtek crap in our builds.

I would suggest you both contact Realtek and urge them to get their drivers added to the mainline kernel. I want to see less out-of-tree Realtek drivers in LibreELEC (ideally: none) and not more, as they're an absolute nightmare to support, so I don't think the RTL8812BU will be supported any time soon I'm afraid.

Realtek really do need to get their sh*t together and stop releasing hardware without in-tree kernel support and then leaving it up to the open source community to bail them out by providing drivers of variable quality.

It's unfortunate that you've already bought the Realtek hardware, with luck maybe you can get a refund and purchase hardware from a vendor (Intel, Broadcom) that has done the right thing and pushed their driver upstream.

What Realtek must do (and Edimax need to be telling Realtek this, too) is push their driver to the main kernel tree. See this post explaining the benefits *for everyone* when drivers are maintained in the kernel tree.

Many Realtek drivers now resemble abandonware as they no longer receive updates from Realtek and are now supported with varying degrees of success by the open source community, usually only to allow them to build with the latest kernels. The driver Edimax pointed you to is no different as it will not build with kernels newer than 4.11.0 - the fixes are available but being ignored which is a classic example of another abandoned driver. Note that the 4.11.y kernel is already obsolete and end of line, so it's not unreasonable to want a driver that builds with the most recent mainline kernel which is 4.13.y (and used by LibreELEC).

So yeah, unfortunately we will not be adding yet another out-of-tree (and most likely already abandoned) Realtek driver into LibreELEC. It really is time Realtek pulled their finger out and did things right. I know this doesn't help you, but long term this is the only sane option.

Edimax Wireless network equipments for small business and home users. www.edimax.com. Our vast and comprehensive product line fulfills all connectivity needs, whatever the network architecture or application requirements are. Our products are...

OK, pulling my hair out - and I can't afford to do that ... LOL! I have 2 USB Wi-Fi adapters, trying to one of them working, to debug another issue - and only needing the USB Wi-Fi as a client, not AP mode. I installed the following packages (opkg),

Please buy a supported WiFi adapter. For example, Alfa Network AWUS036ACM. Exactly "ACM", not any other letter combination. With snapshots, Alfa Network AWUS036AXML will also work, but it has shorter range.

At this point, any adapter based on the MT7612U chipset should work, and, until very recently, that was the only USB3 WiFi chipset supported. I used to recommend searching for "mt7612u" on AliExpress, but the problem is that the RF part and antenna quality varies.

It's a display issue (according to the author of the GitHub you mentioned), so the signal is never 3 dBm but display always showing this thing, I guess they are going to fix it later. However this is not the most important thing, this MT7921u chipset, doesn't seem to be stable enough in AP mode, my COMFAST CF-953AX with OpenWrt has driver crash from time to time (tested with many different devices), especially when high traffic volume it can die very soon.

MT7612U is better but my test is showing mixed results, the one I own isn't really working very fast (kind of disappointed) when compared to my MT7610U (Asus USB-AC51, TPLINK T2U). However for the MT7610U it's really really stable and performing well though it's only USB 2.0, sustained transfer rate 200-230Mbps is an easy task for them, right now I even pair it with one of my older Raspberry Pi to extend WiFi to cover a small corner of my home which my main WiFi isn't able to cover, and it's been a month without any issue at all. Now I am trying to see if I can grab a few more cheaper from AliExpress to augment on my old travel router GL-INET MT300N (it's 2.4GHz only but equipped with 1 x USB 2.0)

I don't see that device to be supported by Linux right now (kernel v6.7) at all. Maybe it's 'just' a case of getting the USB ID added to an existing driver, maybe it needs more efforts - in either way, you will have to engage with mainline linux wireless developers about this (and effectively provide a patch; at the very least find out which chipset is in there, maybe you can open the case and read the chip numbers/ take a photo).

Also here, why do you say that? Not debating, just to understand. And I have that loaded, but it doesn't seem to "attach" to this device (i.e. not taken into use)? And I admit, it's a bit confusing ... do I also need the rtlwifi drivers installed? Not sure if this is causing issues or not.

And another follow-up LOL. I have a feeling I know what is going on, but I admit ... I'm struggling to find where the rtl8xxx code gets pulled in to OpenWrt . And and all pointers appreciated! I will keep digging, but so far spinning in circles.

The potential fix I found is to add options usbcore use_both_schemes=y to /etc/modprobe.d/options. Hmm, that directory doesn't exist in OpenWrt. Not sure where / how to add the option. Still digging, but if anyone knows .

It only 'attaches', if it feels responsible for that USB ID - because it's declared in the driver source (or hot patched via /sys/bus/usb/drivers/rtl8xxxu/new_id, but in the context of OpenWrt that's a tad more complicated).

but in case of rtl8xxxu I'm not very hopeful about that to work, as the driver covers multiple different chipsets under one driver, without being able to tell the driver what chipset it is, there's no big success rate there (you really, really, really want the IDs to be declared in the driver source, properly).

Forgive me that I won't look into the 23.05.x/ backports 6.1 source to check about the details (maybe RTL8XXXU_UNTESTED needs to be set). While you should be able to get it working, it'll (probably) need some (limited) developing, but still would only result in basic client-only support.

If you can get it working on Ubuntu -with rtl8xxxu(!)- (it's going to be easier there, newer kernel version, everything and the kitchen sink enabled by default, firmwares preinstaleld), then it's also possible to do under OpenWrt. And with the knowledge of what (how) it is done on Ubuntu (unless they've gone for vendor drivers), it's easier to replicate on OpenWrt. 'All it needs' then is 'just' doing some driver backports, some packaging changes/ additions, not saying that it's going to be trivial, but doable.

3a8082e126