Hé Habr!
Ik besloot ooit om mijn Raspberry Pi draadloos met het internet te verbinden.
Zo gezegd, zo gedaan: hiervoor werd bij de dichtstbijzijnde winkel een USB Wi-Fi fluitje van het bekende bedrijf TP-Link gekocht. Ik zeg meteen dat dit geen nano-USB-module is, maar een behoorlijk groot apparaat, ongeveer zo groot als een gewone flashdrive (of, als u dat liever heeft, zo groot als de wijsvinger van een volwassen man). Voordat ik tot aankoop overging, bestudeerde ik de lijst met fabrikanten die RPI-fluitjes ondersteunen en TP-Link stond op de lijst (hoewel ik, zoals later bleek, geen rekening had gehouden met de subtiliteiten, want de duivel zit, zoals we weten, in de details). Zo begint het koude verhaal van mijn misavonturen. Uw aandacht wordt getrokken door een detectiveverhaal in 3 delen. Geïnteresseerden kunnen hieronder het gedeelte lezen.
artikel Het heeft mij gedeeltelijk geholpen, maar eerst het volgende.
Probleemstelling
gegeven:
- Singleboardcomputer Raspberry Pi 2 B v1.1 - 1 stuk
- usb wifi fluitje WN727N - 1 stuk
- een paar niet helemaal kromme handen - 2 stuks
- De nieuwste Raspbian (gebaseerd op Debian 10 Buster) is als besturingssysteem geïnstalleerd
- kernelversie 4.19.73-v7+
Zoeken: verbinding maken met internet (Wi-Fi wordt verspreid via een thuisrouter)
Nadat ik de adapter had uitgepakt, las ik de instructies erin:
Systeemcompatibiliteit: Windows 10/8/7/XP (zelfs Sky, zelfs XP) en MacOS 10.9-10.13
Nou ja, zoals gewoonlijk geen woord over Linux. Het was 2k19, maar de drivers moesten nog steeds handmatig worden gecompileerd...
We hadden 2 compilers, 75 duizend bibliotheken, vijf binaire blobs, een halve array van naakte vrouwen met een logo en een hele zee aan headers in allerlei talen en markeringen bij ons. Niet dat het een noodzakelijke set was voor deze taak. Maar zodra je voor jezelf een systeem begint op te bouwen, wordt het moeilijk om te stoppen. Het enige waar ik me zorgen over maakte waren de drivers voor Wi-Fi. Er is niets hulpelozer, onverantwoordelijker en corrupter dan het zelf bouwen van drivers. Maar ik wist dat we vroeg of laat in deze onzin terecht zouden komen.
Over het algemeen is het, zoals bekend, lastig om met USB Wi-Fi op Linux te spelen. pijnlijk en een beetje smakeloos (zoals Russische sushi).
Er zit ook een CD met drivers in de doos. Ik kijk er met gemengde gevoelens naar: ze hebben er duidelijk niet goed voor gezorgd. Na een zoekopdracht op internet kwam ik op de website van de fabrikant terecht, maar daar is alleen een Linux-driver voor de apparaatrevisie beschikbaar. v4, en ik had het in mijn handen v5.21. En ook voor heel oude kernelversies 2.6-3.16. Ontmoedigd door de mislukking in het begin, dacht ik al dat ik de TL-WN727N had moeten nemen (hij is iets duurder en kan 300 Mbps halen, tegenover 150 bij mij, maar voor de Raspberry Pi maakt dat helemaal niets uit, hier schrijf ik later meer over). Maar het allerbelangrijkste is dat de drivers hiervoor al bestaan en eenvoudigweg als pakket worden geïnstalleerd firmware-ralink. De revisie van het apparaat staat doorgaans op een sticker op de behuizing, naast het serienummer.
Na verder googlen en het bezoeken van diverse forums kwam ik niets bijzonders tegen. Blijkbaar had nog nooit iemand vóór mij geprobeerd om deze specifieke adapter op Linux aan te sluiten. Nou ja, ik heb net zoveel geluk als een verdronken man.
Hoewel ik lieg, heb ik ook wat op forums (vooral Engelstalige) gezocht. In sommige topics werd zelfs melding gemaakt van een zekere meneer Lwfinger, die bekend is geworden door het schrijven van een aantal drivers voor wifi-adapters. Zijn git-repository staat aan het einde van het artikel in de links. De tweede les die ik leerde, is dat u uw apparaat moet identificeren om te weten welke driver daarvoor geschikt is.
Deel 1. De Bourne-identiteit
Toen ik het apparaat in de poort stopte, ging er uiteraard geen LED branden. En over het algemeen is het helemaal niet duidelijk of iets werkt of niet.
Het eerste wat ik doe om erachter te komen of de kernel ons apparaat herkent, is kijken naar 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
Het bleek dat hij het zag en het is zelfs duidelijk dat er een Realtek-chip en de VID/PID van het apparaat op de USB-bus zitten.
Laten we verder gaan en eens kijken lsusb, en hier wacht ons weer een mislukking
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
Het systeem weet niet wat voor soort apparaat het is, en toont verlegen een lege spatie in plaats van een naam (hoewel vendor=2357 zeker TP-Link is).
Op dit punt zal de nieuwsgierige lezer waarschijnlijk al iets interessants hebben opgemerkt, maar dat stellen we uit tot het juiste moment.
Toen ik onderzoek deed naar het probleem van de lege naam, kwam ik op een site met identificatiegegevens terecht, waar informatie over bekende VID's/PID's wordt ingevoerd. Onze 2357:0111 was er niet. Zoals later bleek, was het nut lsusb gebruikt bestand /usr/share/misc/usb.ids, wat dezelfde lijst met identificatiegegevens is van deze site. Om de weergave mooier te maken, heb ik eenvoudigweg regels voor de TP-Link-leverancier aan mijn systeem toegevoegd.
2357 TP-Link
0111 TL-WN727N v5.21
We hebben de weergave in de lijst met apparaten hersteld, maar het bracht ons niet dichter bij het kiezen van een driver. Om een driver te selecteren, moet u weten op welke chip uw fluitje is gemaakt. Verdere, vergeefse pogingen om hier op internet achter te komen, leverden niets op. Gewapend met een dunne sleufschroevendraaier wrik ik voorzichtig de dop van de adapter los en mijn blik wordt in al zijn ongerepte naaktheid blootgesteld aan het wrede geesteskind van oom Liao. Onder een vergrootglas kun je de naam van de chip zien - RTL8188EUS. Dat is al goed. Op sommige forums zag ik berichten dat de driver van diezelfde meneer lwfinger wel geschikt is voor deze chip (ook al schreef hij alleen over RTL8188EU).
Deel 2. De Bourne Supremacy
Ik download de driverbronnen van git.
Het is tijd om Windows opnieuw te installeren en te doen waar Linux-gebruikers doorgaans mee geassocieerd worden: iets samenstellen uit bronnen. Het bouwen van drivers verschilt, zo bleek, niet veel van het compileren van programma's:
make
sudo make install
maar om kernelmodules te compileren hebben we de kernelheaderbestanden voor onze specifieke versie nodig.
Er is een pakket in de voorraadopslag raspberrypi-kernel-headers, maar het bevat de kernelversie van de bestanden 4.19.66-v7l+, en dat bevalt ons niet. Maar om de headers van de vereiste versie te verkrijgen, bleek er een handige tool te zijn rpi-bron (link aan het einde op github), waarmee u de vereiste headers kunt downloaden. We klonen de repository, maken het script uitvoerbaar en voeren het uit. De eerste lancering mislukt met een fout - er is geen hulpprogramma bc. Gelukkig staat het in de repository en hoeven we het alleen maar te installeren.
sudo apt-get install bc
Daarna duurt het even om de headers opnieuw op te starten en te downloaden (en dan nog iets in te stellen, ik weet het nu niet meer precies) en kun je weer achteroverleunen. Windows is in al zijn facetten beter geworden.
Nadat alle headers zijn gedownload, controleert u of de directory is verschenen /lib/modules/4.19.73-v7+ en daarin verwijst de symlink naar de plaats waar de gedownloade bestanden zich bevinden (voor mij is dat /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
De voorbereidende fase is voltooid, u kunt beginnen met de montage. Het monteren van de modules neemt wederom de nodige tijd in beslag, de Raspberry Pi is niet bepaald een snelle machine (hij beschikt over een 32bit 900Mhz Cortex ARM v7-processor).
Dus, alles gecompileerd. In stap 2 (make install) installeren we de driver. Tegelijkertijd kopiëren we de firmwarebestanden die nodig zijn om de driver te laten werken:
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/.
Deel 3. Het Bourne Ultimatum
Ik steek het fluitje in de poort en... er gebeurt niets. Was het allemaal voor niets?
Ik begin de bestanden in het project te bestuderen en in een ervan vind ik het probleem: de driver specificeert een volledige lijst met VID/PID-identifiers die hij kan bedienen. En om ons apparaat met deze driver te laten werken, heb ik simpelweg mijn id aan het bestand toegevoegd 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 */
};
De driver opnieuw gecompileerd en opnieuw in het systeem geïnstalleerd.
En deze keer begon alles te werken. Het lampje op de adapter ging branden en er verscheen een nieuw apparaat in de lijst met netwerkinterfaces.
Wanneer u de draadloze interfaces bekijkt, ziet u het volgende:
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 voor degenen die tot het einde lezen
Weet u nog dat ik zei dat het niet uitmaakt wat de maximale snelheid is die op uw adapter staat?
Op de Raspberry Pi (vóór de release van model 4) zitten alle apparaten (inclusief de Ethernet-adapter) op één USB-bus. Best wel gaaf, toch? En daarom wordt de bandbreedte van de USB-bus verdeeld over alle apparaten die erop zijn aangesloten. Bij het meten van de snelheid via zowel Ethernet als USB Wi-Fi (aangesloten op 1 router) en via de lucht en kabel kwam ik uit op ongeveer 20 Mbit/s.
P.S. Over het algemeen is deze handleiding voor het compileren van een driver voor deze specifieke adapter niet alleen geldig voor RPI. Vervolgens heb ik het op mijn desktop met Linux Mint herhaald en daar werkte alles ook. U hoeft alleen maar de vereiste headerbestanden voor de kernelversie die u op dezelfde manier gebruikt, te downloaden.
UPD. Deskundige mensen gaven het volgende advies: om niet afhankelijk te zijn van de kernelversie, moet u drivers compileren en installeren met behulp van dkms. Deze optie staat ook in de readme van de driver
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. Voorgesteld voor apparaat-id werd geaccepteerd in de mainstream-branch van de lwfinger/rtl8188eu-repository.
referenties
-
-
-
-
Bron: www.habr.com
