¡Hola, Habr!
Un día decidí conectar mi Raspberry Pi a Internet de forma inalámbrica.
Dicho y hecho, para ello compré en la tienda más cercana un adaptador USB Wi-Fi de la conocida marca TP-Link. Debo decir que no se trata de un simple módulo USB nano, sino de un dispositivo bastante grande, del tamaño de un pendrive común (o, si lo prefieres, del tamaño de un dedo índice de un hombre adulto). Antes de la compra, investigué un poco la lista de adaptadores compatibles con la RPI y TP-Link estaba en la lista (aunque, como luego descubrí, no consideré algunas sutilezas, ya que el diablo, como se sabe, está en los detalles). Así que, comienza la historia de mis desventuras: se ofrece a su atención una historia de detectives en 3 partes. Los interesados, continúen leyendo.
Artículo me ayudó parcialmente, pero todo a su debido tiempo.
Condiciones del problema
Dado:
- una computadora de placa única Raspberry Pi 2 B v1.1 — 1 unidad
- adaptador USB Wi-Fi WN727N — 1 unidad
- un par de manos no tan torpes — 2 unidades
- como sistema operativo se instaló la última versión de Raspbian (basada en Debian 10 Buster)
- núcleo versión 4.19.73-v7+
Encontrar: establecer conexión a Internet (el Wi-Fi se proporciona desde el enrutador doméstico)
Después de desempaquetar el adaptador, leo la instrucción que viene dentro:
Compatibilidad del sistema: Windows 10/8/7/XP (incluso el cielo, incluso XP) y MacOS 10.9-10.13
Vaya, de Linux como siempre ni palabra. Era 2019, y todavía había que compilar los controladores manualmente ...
Llevábamos con nosotros 2 compiladores, 75 mil bibliotecas, cinco blobs binarios, medio mar de chicas desnudas con logotipo y un océano entero de encabezados de todos los lenguajes y marcas. No es que fuera un conjunto necesario para trabajar. Pero si empezaste a compilar un sistema a tu medida, se vuelve difícil detenerse. Lo único que me preocupaba eran los controladores Wi-Fi. No hay nada más impotente, irresponsable y dañado que compilar controladores a partir de fuentes. Pero sabía que más pronto que tarde también tendríamos que lidiar con eso.
Como se sabe, lidiar con USB Wi-Fi en Linux es doloroso y algo desagradable (como el sushi ruso).
Dentro de la caja había un CD con controladores. Sin muchas esperanzas, miro qué hay en él: claro, no se preocuparon. Buscar en Internet me llevó al sitio del fabricante, pero allí había controlador de Linux solo para la revisión del dispositivo v4, mientras que yo tenía en mis manos la v5.21. Además, es compatible con versiones muy antiguas del núcleo 2.6-3.16. Desalentado por el fracaso desde el principio, pensé que debería haber tomado el TL-WN727N (es un poco más caro y soporta 300 Mbps frente a los 150 de mi dispositivo, pero como resultó ser irrelevante para la Raspberry Pi, de esto se hablará más adelante). Pero lo más importante es que ya hay controladores disponibles para él y se instalan fácilmente mediante un paquete. firmware-ralink. Normalmente se puede ver la revisión del dispositivo en el cuerpo del dispositivo en la etiqueta junto al número de serie.
Más búsquedas en Google y visitas a diferentes foros no trajeron nada bueno. Al parecer, nadie antes que yo había intentado conectar tal adaptador a Linux. Vaya, qué suerte tengo como ahogado.
Aunque no, me equivoqué, las visitas a foros (principalmente en inglés) también dieron sus frutos; en algunos temas apareció la mención de un tal lwfinger, conocido por haber escrito varios controladores para adaptadores WiFi. Su repositorio de Git está al final del artículo en los enlaces. Y la segunda lección que aprendí es que es necesario identificar tu dispositivo para entender qué controlador podría funcionar para él.
Parte 1. Identificación del Dispositivo
Al conectar el dispositivo al puerto, no se encendió ningún LED, y en general no está claro si algo está funcionando o no.
Lo primero que hago para averiguar si el núcleo ve nuestro dispositivo es revisar dmesg:
[ 965.606998] usb 1-1.3: nuevo dispositivo USB de alta velocidad número 9 usando dwc_otg
[ 965.738195] usb 1-1.3: Nuevo dispositivo USB encontrado, idVendor=2357, idProduct=0111, bcdDevice= 0.00
[ 965.738219] usb 1-1.3: Cadenas de dispositivo USB nuevas: Mfr=1, Product=2, SerialNumber=3
[ 965.738231] usb 1-1.3: Producto: 802.11n NIC
[ 965.738243] usb 1-1.3: Fabricante: Realtek
[ 965.738255] usb 1-1.3: Número de serie: 00E04C0001
Resulta que lo ve, y está claro que el chip es Realtek, así como el VID/PID del dispositivo en el bus USB.
Vamos a ver más. lsusb, y aquí nos espera otro fracaso.
Bus 001 Device 008: ID 2357:0111
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Adaptador Ethernet rápido
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
El sistema no sabe qué es este dispositivo y vergonzosamente muestra un espacio vacío en vez de un nombre (aunque vendor=2357 es indudablemente TP-Link).
En esta etapa, el lector curioso probablemente ya ha notado algo interesante, pero dejaremos esto para un poco más adelante.
La investigación sobre el problema de los nombres vacíos me llevó a un sitio con identificadores, donde se registra la información sobre los VID/PID conocidos. Nuestro 2357:0111 no estaba allí. Como descubrí más tarde, la utilidad. lsusb utiliza el archivo /usr/share/misc/usb.ids, que es la misma lista de identificadores de este sitio. Para mejorar la presentación, simplemente agregué en mi sistema las líneas para el proveedor TP-Link.
2357 TP-Link
0111 TL-WN727N v5.21
Bueno, hemos corregido la visualización en la lista de dispositivos, pero eso no nos ha acercado nada a la selección del controlador. Para elegir un controlador, es necesario saber en qué chip se basa tu adaptador. Nuevos intentos fallidos de averiguarlo en internet no han llevado a nada bueno. Armado con un destornillador de cabeza plana, cuidadosamente levanto la tapa del adaptador y se revela ante mis ojos, en toda su primitiva desnudez, la creación defectuosa del tío Liao. Bajo la lupa, se puede ver el nombre del chip — RTL8188EUS. Eso ya es un avance. En algunos foros he visto publicaciones que dicen que para este chip funciona muy bien el controlador de ese caballero lwfinger (incluso a pesar de que solo menciona el RTL8188EU).
Parte 2. La Excelencia de Borna
Estoy descargando el código fuente del controlador desde git.
Ha llegado el momento de reinstalar Windows y hacer lo que normalmente se asocia con los linuxeros: compilar algo desde el código fuente. Compilar controladores, como resultó, poco se diferencia de compilar programas:
make
sudo make install
pero para compilar módulos del núcleo necesitamos los archivos de encabezado del núcleo para nuestra versión específica.
En el repositorio predeterminado hay un paquete raspberrypi-kernel-headers, pero contiene la versión de los archivos para el núcleo 4.19.66-v7l+, y eso no nos sirve. Pero para obtener los encabezados de la versión necesaria, como resultó, hay una herramienta conveniente rpi-source (enlace al final en GitHub), con la que se pueden descargar los encabezados necesarios. Clonamos el repositorio, hacemos que el script sea ejecutable y lo ejecutamos. La primera ejecución falla con un error: falta la utilidad bc. Afortunadamente, está en el repositorio y simplemente la instalamos.
sudo apt-get install bc
Después de esto, la segunda ejecución y la descarga de los encabezados (y luego la configuración de algo, ahora no recuerdo) toma un tiempo, y uno puede relajarse en la silla: Windows se ha vuelto mejor en todas sus facetas.
Después de que se descargaron todos los encabezados, verificamos que apareció el directorio /lib/modules/4.19.73-v7+ y que en él el enlace simbólico apunta al lugar donde están los archivos descargados (para mí es /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
La etapa preparatoria ha terminado, podemos proceder a la ensamblaje. La ensamblaje de los módulos lleva un tiempo determinado, la Raspberry no es un animal rápido (tiene un procesador de 32 bits a 900Mhz Cortex ARM v7).
Así que todo se ha compilado. Instalamos el controlador en el segundo paso (make install), y durante esto se copian también algunos archivos de firmware necesarios para el funcionamiento del controlador:
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/.
Parte 3. El ultimátum de Bourne
Inserto el dongle en el puerto y… no sucede nada. ¿Acaso todo esto fue en vano?
Empiezo a estudiar los archivos dentro del proyecto y en uno de ellos encuentro lo que fue el problema: el controlador especifica una lista completa de identificadores VID/PID que puede manejar. Y para que nuestro dispositivo funcione con este controlador, simplemente añadí mi id en el archivo rtl8188eu/os_dep/usb_intf.c
static struct usb_device_id rtw_usb_id_tbl[] = {
/*=== Placa demoboard de Realtek ===*/
{USB_DEVICE(USB_VENDER_ID_REALTEK, 0x8179)}, /* 8188EUS */
{USB_DEVICE(USB_VENDER_ID_REALTEK, 0x0179)}, /* 8188ETV */
/*=== Identificador del cliente ===*/
/****** 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 */
{} /* Entrada terminante */
};
Recompilé el controlador y lo reinstalé en el sistema.
Y esta vez todo funcionó. La luz del adaptador se encendió y apareció un nuevo dispositivo en la lista de interfaces de red.
Una revisión de las interfaces inalámbricas muestra lo siguiente:
pi@raspberrypi:/home/pi/rtl8188eu# iwconfig
eth0 no wireless extensions.
lo no wireless extensions.
wlan0 unassociated ESSID:"" Nickname:""
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
Bonificación para quienes leyeron hasta el final
¿Recuerdan que dije que no importa cuál sea la velocidad máxima anunciada en su adaptador?
Así que, en la Raspberry Pi (antes del lanzamiento del modelo 4), todos los dispositivos (incluido el adaptador ethernet) están en un mismo bus USB. Increíble, ¿verdad? Y por eso, el ancho de banda del bus USB se comparte entre todos los dispositivos que están conectados. Al medir la velocidad tanto a través de ethernet como de USB Wi-Fi (conectados a un mismo enrutador), obtenía alrededor de 20 Mbit/s.
P.D. De hecho, esta guía para compilar el controlador para este adaptador específico es válida no solo en RPI. Después lo repetí en mi escritorio con Linux Mint, y allí también funcionó. Simplemente necesitas descargar los archivos de encabezado necesarios para la versión del núcleo que estés usando.
UPD. Personas experimentadas sugirieron: para no depender de la versión del núcleo, es necesario construir e instalar controladores usando dkms. Este variante también está en el readme del controlador.
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. Propuesto para el id del dispositivo fue aceptado en la rama principal del repositorio lwfinger/rtl8188eu.
Enlaces
—
—
—
—
Fuente: habr.com
