Wiki List of supported wifi devices

[DHeadshot]

I've finally managed to get working WiFi on the old laptop I mentioned on here some years back!  I found an old Linksys PCMCIA card and tried that and it worked!  I'd post the spec of it, but pccardctl claims it doesn't exist, despite it quite clearly working and lspcmcia only specifies the sockets.  Tinycore version is 6.something, kernel is 3.16.6-tinycore.

If someone can give me some alternative commands to get info I'll post whatever I can find out.

[stephanmg]

Code: [Select]

Edimax Techonology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUs] (WPA-PSK / WPA1/WPA2)
tested with

Code: [Select]

4.19.81-piCore
By the way:

The link (list) of supported Wifi devices does not work for me.

[Leee]

Is anyone currently using a Netgear WNDA3100 v2 (USB wifi dongle with Broadcom BCM4323) with Core 14.x 32 bit?
I just acquired two of these in bunch of tech junk.  They seem to be in working condition but I can't seem to actually get them working.

I found a relevant thread here:

    https://forum.tinycorelinux.net/index.php/topic,12910.msg73169.html#msg73169

but it's over ten years old and mentions ndiswrapper.tcz (which does not seem to be in the 14.x/x86/tcz repo).

lsusb shows the device as

    Bus 003 Device 002: ID 0846:9011 NetGear, Inc. WNDA3100v2 802.11abgn [Broadcom BCM4323]


wireless-6.1.2-tinycore.tcz provides both

    ./usr/local/lib/modules/6.1.2-tinycore/kernel/drivers/net/wireless/broadcom/b43/b43.ko.gz
and

    ./usr/local/lib/modules/6.1.2-tinycore/kernel/drivers/net/wireless/broadcom/b43legacy/b43legacy.ko.gz

although neither of them gets loaded when the extension is loaded.  Manually loading them with modprobe doesn't seem to help.



firmware-broadcom_bcm43xx.tcz seems like it should be relevant as well

wifi.sh (from wifi.tcz) reports "no wifi devices found".

I feel like the pieces are all there but maybe I'm doing something wrong or out of order.

[Rich]

Hi Leee
A search of the Internet suggests there is no kernel support
for that device and that ndiswrapper is required.

Even with ndiswrapper some people reported they could
not get the device to work. The suggestion to switch to
a supported device came up on several occasions.

[Leee]

Thanks Rich.  I'll probably just relegate these to the "maybe Windows" heap.   

[CentralWare]

Hello everyone!

I'm running 14.x x64 on an HP laptop (17-by0036nr) and I randomly grabbed a few short USB dongles (under 1" long outside the USB port) from the office for wireless since the onboard wireless didn't seem to have TCL support. Wouldn't you know... they're all RTL8811 chips, even though three different brand names.  (TP-Link and two generic/unbranded AC devices - what are the odds )

2357:011e TP-Link AC600 wirless Realtek RTL8811AU [Archer T2U Nano]

After a little research...
I have the kernel compiling for 6.1.2 and will be rolling up a RTL88xxAU driver here in a little while as the internal wifi chip (RTL8327) was deleted last year from the Realtek firmware for 14.x for some reason, so I have to rebuild the module anyway if I want to use this laptop for the project in question...

So, what's our take on non-kernel drivers such as this? Do we build extensions "as is" or simply not support them?

REF: HP:17-BY0036NR WIFI:TCL:RTL8723DE WIFI:TCL:RTL8811AU

[Juanito]

I’d say build extensions as needed.

[curaga]

Yeah, external modules are fine as extensions (including binary drivers like Nvidia as long as their license allows).

[Paul_123]

I caution you on being a maintainer supporting Realtek product.  I used to manage them for a different system, and it became unmanageable due to the constant state of flux with 3rd party repos (updating for newer kernels, or they stopped working).  There is some kernel work trying to build a intree realtek kernel driver, but its support is very limited right now.

I think the simpler approach is to wiki how to build your own driver.

I found this to be the most complete information on what works for USB wifi.
https://github.com/morrownr/USB-WiFi/tree/main

PS. I build the 8812au driver for my own personal use.

[CentralWare]

@Paul_123: Maintaining anything third party tends to come with inherent hazards (ie: No good deed goes unpunished)
I was thinking more in the direction of an extension based on necessity here...  and with 15.x being on the anvil as we speak, likely compiled for that era as well...  build instructions and the likes included with a note in the .info "...if it doesn't work for you, here's how to build your own...  G'luck!" by which time, for all we know, that vintage of RTLs could make it into the main-stream.

github:morrownr is actually where I was reading up on the RTL8821/11 and 8822/12 before reaching out

@curaga / @Juanito: Thanks!
Any time we create something on this end that originates in part or in whole elsewhere, I tend to copy the (C) and distribution terms verbatim; or at least provide a link of where to find the red-tape.  Granted, sometimes "free to distribute" (CDDL) does not always mean "freely distribute" (GPL) so... either scrub the mission, or "...better to ask forgiveness..." when the grey area is too gray!

EDIT: Disregard everything...  if I'm understanding correctly, 8821CE (PCIe) and AU (USB) are kernel supported in >= 6.3.x and our 14.x is running 6.1.2
Will know for certain here in a while -- will be downloading 6.6 and digging in.

PCIe...  yes.  USB...  no. 
Well, at least my own build seems to be working nicely.

[CNK]

I caution you on being a maintainer supporting Realtek product.  I used to manage them for a different system, and it became unmanageable due to the constant state of flux with 3rd party repos (updating for newer kernels, or they stopped working).

For the r8168 PCIe Ethernet driver I've found the patches that Debian publish for their corresponding r8168 driver package very handy to fix build problems with newer kernel versions.

[CentralWare]

@CNK: Yes, working up-stream occasionally has its advantages

Thankfully, the 8821/8822 chipset drivers compile without too much effort (mostly path related issues since placing the ko in /lib is where it wants to go, but most extension files are expected to live in /usr(/local/lib/modules/) plus the extension itself still needs a little TLC; I went to strip the resulting binary and it gained quite a bit of weight instead of losing it, so we'll be digging a little deeper there before submitting, but otherwise submitqc says it's happy.

[Rich]

Hi CentralWare

... (mostly path related issues since placing the ko in /lib is where it wants to go, but most extension files are expected to live in /usr(/local/lib/modules/) ...

You know those extension files can also be reached through:

Code: [Select]

/lib/modules/$KERNEL/kernel.tclocal/

[CentralWare]

@Rich: I was under the impression that all extension related content was expected to call /usr/local home and to avoid blending in with /var ?

[Rich]

Hi CentralWare
Sorry, my response was poorly worded.
Extension files go in /usr/local/lib/modules/$KERNEL/kernel/
However, the  rootfs.gz  includes a link to that location:

Code: [Select]

tc@E310:~$ readlink /lib/modules/4.19.10-tinycore/kernel.tclocal
/usr/local/lib/modules/4.19.10-tinycore/kernel/
tc@E310:~$