We are friends RaspberryPi with TP-Link TL-WN727N

Hey Habr!

I thought of somehow connecting my raspberry to the Internet by air.

No sooner said than done, for this, a whistle from the notorious TP-Link company was purchased at the nearest usb wi-fi store. I must say right away that this is not some kind of nano usb module, but quite an overall device about the size of an ordinary USB flash drive (well, or if you like, with the index finger of an adult man). Before buying, I studied the list of supported whistle manufacturers for RPI and TP-Link a little (however, as it turned out later, I did not take into account the subtleties, because the devil, as you know, lies in the details). So, a cold tale about my misadventures begins, a detective story in 3 parts is offered to your attention. Interested please under cat.

Article Connect WiFi adapter WN727N to Ubuntu/Mint I partially helped, but first things first.

Conditions tasks

Given:

  1. single-board computer Raspberry Pi 2 B v1.1 - 1 piece
  2. usb wi-fi whistle WN727N — 1 piece
  3. a pair of not quite crooked hands - 2 pieces
  4. latest Raspbian installed as OS (based on debian 10 Buster)
  5. kernel version 4.19.73-v7+

Find: connect to the Internet (Wi-Fi is distributed from the home router)

After unpacking the adapter, I read the instructions inside:

System Compatibility: Windows 10/8/7/XP (even sky, even XP) and MacOS 10.9-10.13

Hmm, about Linux, as usual, not a word. It was 2k19, and the drivers still needed to be assembled manually ...

We had 2 compilers with us, 75 thousand libraries, five binary blobs, half an array of naked women with a logo and a whole sea of ​​headers of all languages ​​and markups. Not that it was a necessary set for the job. But once you start to assemble the system for yourself, it becomes difficult to stop. The only thing that caused me concern was the drivers for wi-fi. There is nothing more helpless, irresponsible and corrupt than building drivers from source. But I knew that sooner or later we would switch to this rubbish.

In general, as you know, fuss with usb wi-fi on Linux is painful and somewhat uncomfortable (like Russian sushi).

There is also a driver CD in the box. Without much hope, I look at what is on it - for sure, they didn’t take care of it. An Internet search brought me to the manufacturer's website, but there is a Linux driver only for device revision v4and I had in my arms v5.21. And besides, under very old versions of the kernel 2.6-3.16. Discouraged by the failure already at the very beginning, I already thought that I should have taken the TL-WN727N (it is a bit more expensive and can do 300Mbps versus 150 for mine, but as it turned out, it doesn’t matter for the raspberry at all, this will be written later). But the most important thing is that there are already drivers for it and they are installed simply as a package firmware-ralink. You can usually view the revision of the device on the device case on a sticker next to the serial number.

Further googling and visiting different forums did not bring much good. Apparently no one before me tried to connect such an adapter to Linux. Hmm, I'm lucky as a drowned man.

Although no, I’m lying, visiting forums (mostly English-speaking) also bore fruit, in some topics there was a mention of a certain Mr. lwfinger, who is famous for writing a number of drivers for Wi-Fi adapters. His git repository is at the end of the article in the links. And the second lesson I learned is that you need to identify your device in order to understand which driver can suit it.

Part 1. Bourne Identification

When the device is plugged into the port, no LED lights up, of course. And in general, it is not clear in any way that something works or not.

First of all, to find out if the kernel sees our device, I look in dmesg:

[  965.606998] usb 1-1.3: new high-speed USB device number 9 using dwc_otg
[  965.738195] usb 1-1.3: New USB device found, idVendor=2357, idProduct=0111, bcdDevice= 0.00
[  965.738219] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  965.738231] usb 1-1.3: Product: 802.11n NIC
[  965.738243] usb 1-1.3: Manufacturer: Realtek
[  965.738255] usb 1-1.3: SerialNumber: 00E04C0001

It turned out that he sees, and it’s even clear that there is a Realtek chip and the VID / PID of the device itself on the usb bus.

Let's move on, let's see lsusb, and here we are waiting for another failure

Bus 001 Device 008: ID 2357:0111 
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The system does not know what kind of device it is, and bashfully shows an empty space instead of a name (although vendor=2357 is definitely TP-Link).

At this stage, the inquisitive reader has probably already noticed something interesting, but we will postpone it until our time.

Researching the problem of empty names led me to a site with identifiers, where information on known VID / PID is entered. Our 2357:0111 was not there. As it turned out later, the utility lsusb uses file /usr/share/misc/usb.ids, which is the same list of ids from that site. For the beauty of the display, I simply added lines for the TP-Link vendor to it in my system.

2357  TP-Link
        0111  TL-WN727N v5.21

Well, we corrected the display in the list of devices, but this didn’t bring us one step closer to choosing a driver. To select a driver, you need to know on which chip your whistle is made. The next unsuccessful attempts to find out on the Internet did not lead to anything good. Armed with a thin slotted screwdriver, I carefully pry off the lid of the adapter and my gaze appears in all its primordial nudity, the vicious brainchild of Uncle Liao. Under a magnifying glass, you can see the name of the chip - RTL8188EUS. It's already good. On some forums, I saw posts that just the driver of the same gentleman lwfinger is well suited for this chip (even though he only says about RTL8188EU).

Part 2. The Bourne Supremacy

I download the source code of the driver from the git.

It's time to reinstall the windows to do what Linuxoids are usually associated with - assembling something from sorts. As it turned out, assembling drivers differs little from compiling programs:

make
sudo make install

but in order to compile kernel modules, we need the kernel header files for our particular version.

There is a package in the stock repository raspberrypi-kernel-headers, but it contains the kernel version of the files 4.19.66-v7l+and that doesn't work for us. But to get the headers of the desired version, as it turned out, there is a convenient tool rpi source (link at the end of the github), with which you can download the desired headers. We clone the repository, make the script executable, run it. The first launch fails with an error - there is no utility bc. Fortunately, it is in the repository and we just install it.

sudo apt-get install bc

After that, restarting and downloading headers (and then setting up something, I don’t remember now) takes some time and you can lean back in your chair Windows has become better in all its manifestations.

After all the headers have downloaded, we check that the directory has appeared /lib/modules/4.19.73-v7+ and in it the symlink points to the place where the downloaded files are located (I have it /home/pi/linux):

pi@raspberrypi:/home/pi/rtl8188eu# ls -l /lib/modules/4.19.73-v7+/
lrwxrwxrwx  1 root root     14 Sep 24 22:44 build -> /home/pi/linux

The preparatory stage has been completed, you can start assembling. The assembly of modules again takes a certain time, the raspberry is not a fast beast (it has a 32bit 900Mhz Cortex ARM v7 stone).
So everything compiled. We install the driver in the 2nd step (make install), while copying more firmware files necessary for the driver to work:

install:
        install -p -m 644 8188eu.ko  $(MODDESTDIR)
        @if [ -a /lib/modules/$(KVER)/kernel/drivers/staging/rtl8188eu/r8188eu.ko ] ; then modprobe -r r8188eu; fi;
        @echo "blacklist r8188eu" > /etc/modprobe.d/50-8188eu.conf
        cp rtl8188eufw.bin /lib/firmware/.
        /sbin/depmod -a ${KVER}
        mkdir -p /lib/firmware/rtlwifi
        cp rtl8188eufw.bin /lib/firmware/rtlwifi/.

Part 3. The Bourne Ultimatum

I stick a whistle into the port and ... nothing happens. Was it all for nothing?

I start to study the files inside the project and in one of them I find what the problem was: the driver has a complete list of VID / PID identifiers that it can serve. And in order for our device to work with this driver, I just added my id to the file rtl8188eu/os_dep/usb_intf.c

static struct usb_device_id rtw_usb_id_tbl[] = {
        /*=== Realtek demoboard ===*/
        {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x8179)}, /* 8188EUS */
        {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x0179)}, /* 8188ETV */
        /*=== Customer ID ===*/
        /****** 8188EUS ********/
        {USB_DEVICE(0x07B8, 0x8179)}, /* Abocom - Abocom */
        {USB_DEVICE(0x0DF6, 0x0076)}, /* Sitecom N150 v2 */
        {USB_DEVICE(0x2001, 0x330F)}, /* DLink DWA-125 REV D1 */
        {USB_DEVICE(0x2001, 0x3310)}, /* Dlink DWA-123 REV D1 */
        {USB_DEVICE(0x2001, 0x3311)}, /* DLink GO-USB-N150 REV B1 */
        {USB_DEVICE(0x2001, 0x331B)}, /* D-Link DWA-121 rev B1 */
        {USB_DEVICE(0x056E, 0x4008)}, /* Elecom WDC-150SU2M */
        {USB_DEVICE(0x2357, 0x010c)}, /* TP-Link TL-WN722N v2 */
        {USB_DEVICE(0x2357, 0x0111)}, /* TP-Link TL-WN727N v5.21 */
        {}      /* Terminating entry */
};

Recompiled the driver and reinstalled it in the system.

And this time everything worked out. The light on the adapter lights up and a new device appears in the list of network interfaces.

Viewing wireless interfaces gives the following:

pi@raspberrypi:/home/pi/rtl8188eu# iwconfig
eth0      no wireless extensions.

lo        no wireless extensions.

wlan0     unassociated  ESSID:""  Nickname:"<WIFI@REALTEK>"
          Mode:Auto  Frequency=2.412 GHz  Access Point: Not-Associated   
          Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=0/100  Signal level=0 dBm  Noise level=0 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Bonus for those who read to the end

Remember how I said that it doesn't matter what maximum speed is declared on your adapter?
So, on the raspberry (before the release of model 4), all devices (including the ethernet adapter) sit on the same usb bus. It's great, right? And so the bandwidth of the usb bus is shared between all devices on it. When measuring the speed both via ethernet and via usb wi-fi (connected to 1 router) both over the air and over the wire it gave out around 20Mbps.

PS In general, this guide for compiling a driver for this particular adapter is valid not only for RPI. I then repeated it on my desktop with Linux Mint - everything worked there too. You just need to download the necessary header files for your kernel version in the same way.

UPD. Knowledgeable people suggested: in order not to depend on the kernel version, you need to build and install drivers using dkms. The readme for the driver also has this option.

pi@raspberrypi:/home/pi# sudo dkms add ./rtl8188eu
pi@raspberrypi:/home/pi# sudo dkms build 8188eu/1.0
pi@raspberrypi:/home/pi# sudo dkms install 8188eu/1.0

UPD2. Proposed patch for device id has been accepted into the mainstream branch of the lwfinger/rtl8188eu repository.

references
RPi USB WiFi Adapters
Gitbub lwfinger/rtl8188eu
usb.ids
rpi source

Source: habr.com