What wireless usb chipset is compatible with Ubuntu 16.04

Hi all I need to know that Wireless USB chipset is compatible with Ubuntu 16.04 Mate. I tried rtl8192cu and rtl8192eu but give me problems with fstab, not mounted folders.

Thank you.

Linux drivers are a function of the kernel support. They are listed at /lib/modules/4.4.0-36-generic/kernel/drivers/.

The 4.4.0-36-generic directory above should be changed according to the kernel version running on your system. It is usually the latest version you see listed under /lib/modules, but if you started your linux with another kernel, or want to be sure, run the command uname -r

$ uname -r

Wireless USB drivers are listed under the directory above, inside net/wireless/.

The driver files have a .ko extension. The directories and files follow a simple convention on which the x character is single character placeholder. So, the /lib/modules/4.4.0-36-generic/kernel/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.ko driver file is not the driver for both the rtl8192cu and rtl8192eu chipsets. They are missing an ‘x’.

You will find those drivers under /lib/modules/4.4.0-36-generic/kernel/drivers/net/wireless/realtek/rtlwifi. The rtl8192cu is listed there, but not the rtl8192eu. It is possible that this driver is not supported or it uses the more generic rtlwifi.ko driver also listed there.

To know which driver (if any) your rtl8192eu device is using, you plug in the device and then list the available hardware:

$ sudo lshw -C net

(The -C option is a way to limit the output to just a class of hardware; on this case network hardware. Otherwise lshw will print a lot of stuff you don’t really need.)

For the listed device, under the configuration label, you’ll see the named driver. I can’t show you any of those two devices because I don’t have them, but i’ll show you the output of that command on my own machine and help you locate the named driver (note the r8169 named driver, under the configuration label):

       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:03:00.0
       logical name: enp3s0
       version: 03
       serial: bc:ae:c5:32:6d:1e
       size: 10Mbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix vpd bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=half firmware=rtl_nic/rtl8168d-2.fw latency=0 link=no multicast=yes port=MII speed=10Mbit/s
       resources: irq:35 ioport:b800(size=256) memory:f2fff000-f2ffffff memory:f2ff8000-f2ffbfff memory:f7cf0000-f7cfffff

with that information you can now use the modinfo tool to obtain more information about the driver, including its location and version number.

$ modinfo r8169

Alternative way:
You can use the dmesg command. Plug in your device and then run dmesg | tail -n20. That will show you the last 20 lines of the kernel buffer and you will see the entry where your device is being plugged in along with the driver name. Then you can use modinfo as above.

However, this way the driver name is a bit harder to detect to an untrained eye. It’s usually on the same line of the output that names the device and before a version number or, for network devices, before a string of colon-delimited alphanumeric values which represent the device MAC address. Here’s the output of dmesg after inserting a common USB pen on my computer:

[ 9215.772405] usb 1-1.6: new high-speed USB device number 4 using ehci-pci
[ 9215.868657] usb 1-1.6: New USB device found, idVendor=0930, idProduct=6544
[ 9215.868663] usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9215.868668] usb 1-1.6: Product: TransMemory     
[ 9215.868671] usb 1-1.6: Manufacturer: TOSHIBA 
[ 9215.868674] usb 1-1.6: SerialNumber: 33C9D732C397CD406BA10974
[ 9215.869232] usb-storage 1-1.6:1.0: USB Mass Storage device detected
[ 9215.871099] scsi host13: usb-storage 1-1.6:1.0
[ 9216.895889] scsi 13:0:0:0: Direct-Access     TOSHIBA  TransMemory      1.00 PQ: 0 ANSI: 4
[ 9216.896461] sd 13:0:0:0: Attached scsi generic sg5 type 0
[ 9216.897574] sd 13:0:0:0: [sdd] 30297216 512-byte logical blocks: (15.5 GB/14.4 GiB)
[ 9216.898315] sd 13:0:0:0: [sdd] Write Protect is off
[ 9216.898323] sd 13:0:0:0: [sdd] Mode Sense: 45 00 00 00
[ 9216.899104] sd 13:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA

on this case the driver is named on the 7th line; usb-storage.

Ok… so, you will very likely find that Linux does support those two devices. We know for sure that rtl8192cu is supported, and the eu version almost certainly too, although through a more generic driver. So, why are you having problems.

The answer is complicated. We need more information on what you are trying to do. Usually it is just something simple, like a wrong configuration. But it can likely also be that those drivers aren’t that good and only provide minimal support. It is not uncommon for users of certain wireless devices to have to blacklist a driver module on linux and download, compile and install a third-party provided driver for their device to start working.

1 Like

Thank you for responding, I’ll take me a little time to read it, my English is not very good.

Hi I’ve been testing and I have concluded it must be a bug in the kernel 4.4. and the fstab file.
Why I have come to this conclusion?
I’ve been testing with several wireless adapters USB chip rtl8188cus, rtl8192cu and RTL8187B, on the same team but with different distributions.
With Ubuntu Mate 16.04 has kernel 4.4 connection adapters have no problems but adapters with chipset rtl8188cus and rtl8192cu not ride the nfs folders at the beginning (has to do with the query: Nfs client configuration), the RTL8187B chipset done correctly.
With Linux Mint 17.3 with kernel 3.19 gives no problems.
With Debian 8 kernel 3.16 either.

Hello everyone, I finally think I’ve solved the problem.
The solution I found on the wiki Arch.

Simply add in fstab the following commands:

noauto, x-systemd.automount, x-systemd.idle-timeout = 1min

Example: / pc2 / folder2 nfs noauto, x-systemd.automount, x-systemd.idle-timeout = 1min, hard, intr 0 0