El Taller de Luis

Categoría: Post random

  • Las Raspberry Pi pueden con más de un disco, y lo he probado

    Las Raspberry Pi pueden con más de un disco, y lo he probado

    Orgullosamente escrito sin IA 🙂

    Desde hace un tiempo tengo esto como un servidor en casa:

    Una Raspberry Pi 4, foto ilustrativa

    Esto funciona como un NAS (network attached storage).
    ¿Qué hace? Me permite poder guardar cosas en el disco externo (3 TB) y acceder a ellas remotamente, aprovechando el internet fijo y sin pagar servicios cloud a nadie 🙂

    Al momento el Raspberry está funcionando bien, y el CPU lleva usándose poco:

    Los picos de consumo son por las verificaciones (scrub) que ZFS hace de todo el disco cada mes.

    Problema

    El sistema operativo está instalado en una microSD. Esta es la forma favorita de ponerle almacenamiento: fácil de conseguir, de instalar y barata.

    La microSD en cuestión, Funcionó muy bien por cuatro o cinco años.

    A pesar de que la memoria que usé funcionó por un largo tiempo, se ha ido quedando corta. Para un NAS donde solo obtengo archivos ocasionalmente funciona bien, pero eventualmente fui instalando más cosas:

    • Un servidor Jellyfin para ver series/películas
    • Smokeping, para monitorizar los pings hacia otros puntos LaOtraRed
    • speedtest-tracker, para monitorizar la velocidad de Internet y verificar que estoy recibiendo el servicio por el que estoy pagando.
    • Un caché local de repositorios Linux

    No es mucho xD ya que la mayoría de lo que uso está en LaOtraRed, pero la escritura constante ya va desgastando al microSD (que tiene una duración mucho menor a la de un SSD convencional). Pensé en mover todo al disco externo ya conectado, pero un HDD puede ser bastante lento para este tipo de uso.

    Posibles soluciones

    Lo más obvio es migrar a un SSD. Esto es fácil, solo debes conseguir un SSD y un adaptador que lo haga compatible con USB3.

    Desde el Raspberry Pi 4 es posible bootear sin microSD y solo por USB (en la versión 3 el soporte era esporádico), y para eso debemos tener el firmware actualizado:

    Luego de eso conecté el SSD. Esto fue un fracaso, más que nada porque ya tenía el HDD conectado. Esto generó errores en dmesg y pude intuir que el Raspberry Pi no podía darle energía a ambos al mismo tiempo.

    No era compatible, por tanto cancelé la idea y la dejé así por casi un año.

    Descargar ese consumo a otra parte

    El concepto de traspasar la carga (offload) es interesante. En Linux lo veo mucho cuando se busca implementar mecanismos que traten de evitar «caminos costosos».

    Por ejemplo: si tienes un router Gigabit, probablemente el switch integrado switchee 1Gbps sin problemas en una red local, pero la velocidad para el enrutado + NAT + firewall (esencial en un router que sale a Internet) está limitado a mucho menos que eso. Y es porque todo lo que maneja eso, la infraestructura de firewall en Linux, es un «camino costoso» y complejo.

    Para ser más eficiente, Linux implementa offload de dos maneras:

    • Software Flow Offload: si el firewall ya permitió por ejemplo, negociar una conexión TCP, no tiene sentido seguir evaluando filtros para los paquetes de datos que siguen en esa conexión, que sabemos ya están autorizados para ingresar.
      Cuando descargas algo pesado, SFO hace que estos paquetes de datos se salten mucho del «camino costoso» y puedan pasar más rápido en mayor cantidad. Es compatible con cualquier hardware que corra Linux.
    • Hardware Flow Offload: A pesar de que SFO ahorra camino, sigue yendo hacia el CPU y procesándose en el kernel. HFO va un paso más allá: hace que el mismo SoC del router (chip) haga el enrutado + NAT usando un procesador especial. De esta manera, todo ese tráfico pesado nunca toca Linux y pasa por el router a la mayor velocidad posible.
      Claro, esto solo funciona si tienes un chip con soporte de enrutado en capa 3 por hardware.

    Sé que USB en los Raspberrys no son diferentes que los de una PC, y sería bueno encontrar alguna manera de hacer «offload» de esa carga energética a otra parte.

    Un Hub USB

    Casi siempre he usado hubs baratos, y los resultados fueron horribles si trataba de usarlos para algo que no sea uso convencional: dejaban de funcionar, ocasionalmente corrompían datos o su «entrada de energía independiente» devolvía 5V al cable que va hacia el Raspberry, amenazando con quemarlo. Todo hasta que llegó este Cudy UH407:

    Lo compré de la Calatayud y era para aprovechar el puerto USB-C de mi laptop, puerto que apenas uso. No recuerdo cuando costó.

    Lo interesante: este hub viene con Power Delivery Passthrough: puedes conectarlo a tu laptop, y conectando un cargador al hub, este alimentará el hub y tu laptop también. Queda muy bonito cuando todos los periféricos de tu escritorio están conectados al hub y de ahí a tu laptop usando un solo cable, sin nada más.

    Bueno, ya que este puerto PD carga el hub… nos servirá para una Raspberry?

    Detour: alimentar una Raspberry por Power Delivery Passthrough

    Se puede armar algo como esto:

    ¡Resulta que funciona! Casi nadie hace esto 😉 Para hacerlo necesitas estos requisitos:

    • Una Raspberry Pi 4 con versión de hardware 1.2+, las anteriores tienen un bug de hardware en la placa y no soportan PD bien. Probé con otra placa que es una 1.1 y no funcionó 🙁
    • Tener la configuración dtoverlay=dwc2,dr_mode=host en /boot/firmware/config.txt
    • Un kernel Linux 6.6+ o superior

    Funciona, pero el puerto USB-C de la Raspberry es solo USB2. No es suficiente para usarlo con el SSD, pero aún así lo escribo ya que a alguien le puede servir.

    El setup perfecto

    El Raspberry no puede mandar energía por USB que supere cierto límite, incluso si tienes un adaptador que pueda darle más de 3 amperios. Para hacerlo hay que ponerse a soldar (no recomendable), o mejor, usar un hub de esta manera.

    Con un adaptador USB-C hembra a USB normal, ahora el hub puede ser usado. Conecté dos discos duros ahí (uno más de lo previsto) y alimenté todo eso con un cargador Cudy CH20, que por 50 Bs más me da 5V 3A para disponer con comodidad 😀

    Ahí se ve todo funcional. Las 3 unidades se reconocen sin problema 😀

    Alternativas

    Ojo que fui a comprar otros modelos y traté de replicar esto con un Cudy UH405 (más barato, con PD y un solo puerto USB3 mas dos USB2). No funcionó, cada vez que le llega primero energía por PD este se bloquea y no enumera los aparatos USB que tiene conectados.
    El UH407 no tiene este problema, ¡muy bien por el team que programó su firmware!

    Próximamente

    El adaptador de SSD NVMe a USB que usé. Existe uno que creo es el mejor (buena velocidad, bajo consumo, buena compatibilidad y bajas temperaturas) y comentaré cómo conseguirlo y configurarlo.

  • 1 Gbps de Internet para Informática UMSA Parte 2: Switches

    1 Gbps de Internet para Informática UMSA Parte 2: Switches

    Ya tenemos el punto Gigabit en el piso 2. Ahora es responsabilidad del laboratorio ITIC hacer llegar esa conexión a los pisos y lugares. Pero tenemos problemas:

    1. Distintos árboles de switches
    2. Puertos Gigabit troncales sin usar
    3. Heterogeneidad en los puntos de acceso

    Distintos árboles de switches

    Las redes instaladas en la carrera estaban realmente separadas entre sí: si tenías una IP del tipo 192.168.60.x no podías llegar a otra IP del rango 192.168.17.x.

    Esto ayuda a manejar tráfico con distinta prioridad, y un exceso en un punto no perjudica el internet del resto. Pero ese ya no es el caso y tenemos tres redes separadas para unir, lo que nos fuerza a revisar todas las conexiones.

    Luego de eso llegamos al siguiente problema:

    Troncales incorrectas

    Cuando armas una red en esta topología, los switches concentran el tráfico de muchas máquinas a un solo puerto.

    Al contrario que un switch barato, estos switches vienen con el concepto de puerto de subida o upstream. En estos, el switch te da puertos 1Gbps: de esta manera, por probabilidad un puerto 100Mbps va a tener más tiempo para saturar su puerto con tráfico sin que otro tráfico le moleste.

    Un puerto de 1 Gbps trae 1000 Mbps. Diez puertos de 100 Mbps pueden saturarlo, pero la probabilidad de que eso suceda son bajas. Así podemos conseguir que cada persona que use un puerto de 100 Mbps, pueda usarlo por completo y sin afectar al resto.

    Como las conexiones de Internet originalmente fueron de 15 Mbps y de ahí fueron subiendo, se siguió la convención de reservar el puerto 1 como puerto upstream, y usar solo los puertos 2 en adelante para los demás equipos.

    El problema llega cuando instalamos la nueva red: el puerto 1 usado no es Gigabit (los puertos de este tipo son el 49-50 o Gi1/Gi2) y ahora casi todos los switches de la carrera tienen un cuello de botella.

    Esto se soluciona yendo a cada piso, reconfigurando cada switch a mano, identificando el cable adecuado y reconectándolo en un puerto Gigabit.

    Luego de revisar, podemos asegurarnos que el tráfico está yendo por los puertos correctos:

    La meta es poder tener una configuración como esta:

    Me complace anunciar, que gracias al trabajo que estuve haciendo como voluntario a fines de 2025 en la oficina, todos los switches usan troncales Gigabit. Hay varias mejoras por hacer y continuaré escribiendo sobre ello.

  • 1 Gbps de Internet para Informática UMSA Parte 1: Historia

    1 Gbps de Internet para Informática UMSA Parte 1: Historia

    Los trabajadores de una empresa privada están en un agujero en el piso. Cumplen la noble labor de pasar cables de fibra óptica desde el monoblock hacia la Sala de Servidores del edificio. Es un día soleado de Febrero y, aunque para muchos es un día normal, este será luego un hito histórico propiciado por trabajos iniciados desde 2023.

    La Carrera ahora migra a un Internet 10 veces mejor, con su primer enlace dedicado 1Gbps simétrico hacia la red de la UMSA.

    Quiero contarte la experiencia desde el punto de vista de un auxiliar random que ayudó en algo a echar andando este proyecto.

    Cómo era la situación en ese entonces

    Previamente, el contacto más directo con la red de la UMSA era el Wi-Fi «UMSA». Con un punto en la biblioteca y en un depósito dentro del sótano, la experiencia siempre fue negativa por la saturación. En horas normales, la biblioteca estaba casi siempre llena y no podías obtener más de 5 o 4 Mbps.

    Antes, el límite de tráfico era sólo para el internet. Si tenías otro punto en la red interna de la UMSA tenías tráfico ilimitado hacia el lugar, siempre podías tener más velocidad con un proxy o VPN. Pero, eventualmente la UMSA migró su contrato de AXS a Comteco y ahora tenía el ancho de banda suficiente para quitar los límites.

    Antes el truco para obtener mejores velocidades era pivotar el tráfico por un «servidor» adicional cableado dentro de la red. Una de las versiones de las Pasankallas hacía eso y liberaba el ancho de banda para que cualquiera lo use.

    ¿Es bueno? Sí, pero esto expuso otro grave problema: la infraestructura local.

    El edificio de Informática cuenta con sus propias redes: segmentos de servidores, redes administrativas y laboratorios estaban todos separados. Además, existían tres conexiones de internet AXS (algunas ADSL, otras se migraron a GPON) donde estaban los servicios más importantes, como el sistema de notas o de inscripciones.

    Estos servicios importantes se migraron al datacenter de DTIC y ahora solo queda en la sala de servidores el acceso a internet de la carrera.

    Todo con switches de 100 Mbps.

    Yo me había dado cuenta con las pruebas de velocidad que siempre hacía. Iba muy temprano a la carrera, apenas abrieran y tenía como 70 Mbps, cifra que se reducía a 3 Mbps al testear de nuevo en hora pico. Trucos para mejorar el ancho de banda, como mi túnel IP over UDP con Erasure Coding (que implementé en alguna versión de la Pasankalla) dejaron de funcionar en absoluto.

    Conseguir el modelo de las antenas no fue complicado (Ruckus T300 claramente prestado para el CLEI de ese año), y eso me hizo sospechar. Esa antena tenía capacidad para mucho más, pero tenía un cuello de botella en, quizás, un puerto de 100Mbps.

    Este es el problema. La carrera, en su momento máximo tuvo conexiones donde cada una tenía un tope de 100 Mbps, por tanto nunca hubo la necesidad de revisar configuraciones.

    Ahora tenemos 1Gbps simétrico

    Estuve presente en el «light up», o sea, donde la fibra óptica instalada se «ilumina» y se arma un enlace.

    Pude hacer la prueba final yo mismo:

    VIDEO: https://video.laotra.red/w/mWXxjhCk69WGP38h1QRVwR

    Otra prueba que hice al enlace bastante después.

    Cambios en la arquitectura

    Cosas como los sistemas de notas del pasado (SIA, DNSIA) nos muestran una cultura de apropiación, donde «como informáticos, sabemos cómo manejar nuestros propios sistemas».

    Nuestro sistema de notas, el SIA. Funcional, si mal no recuerdo, desde 2004 hasta 2017. Escrito en PHP, casi nunca recibió mejoras o actualizaciones, y ya se imaginan cómo le fue.

    En estos años la carrera tuvo un cambio de pensamiento. Cada vez los servicios se están centralizando a manos de DTIC y DIRESI: el sistema de notas e inscripciones ahora es diferente y funciona desde el Edificio Hoy, y ahora el servicio de internet viene desde un circuito que se origina en el Monoblock, y ya no desde un splitter GPON de AXS en la Federico Zuazo.

    Esto nos provee una ventaja. La fibra de la UMSA que nos llega es una troncal (viene con varias VLANs) y nos facilitaron una con la red 172.16.4.0/23, ¡lista para usar! Así ya se puede proveer el servicio desde el día 0, sin tener que gestionar por nuestra cuenta el DHCP, NAT y servicios de ese tipo (que es fácil hacerlos mal).

    Ya tenemos el Internet. Ahora, ¿cómo se hace para que esta velocidad llegue a los demás pisos e instalaciones de la Carrera?

    Esto en la parte 2 de esta serie de blogs.

  • Rescatando una placa vieja Parte 1: Linux Moderno

    Encontré esto en la feria 16 de julio:

    Tenemos la memoria RAM (esquina superior derecha), memoria flash detrás de la placa, un CPU Atheros, todo esto esencial para considerar algo una computadora. Además tenemos una interfaz de red y USB.

    ¿Será que podemos correr Linux acá?

    Conociendo la placa

    Revisando la caja de plástico, dice que es un TP-Link MR3020. Nueva se vería algo así:

    Supuestamente esta no funciona al momento de comprarla, y al probarla en casa, efectivamente solo el LED de energía se prende. El puerto Ethernet igual está muerto y no hay señales de que se esté emitiendo alguna red Wi-Fi.

    Software adicional

    Reseteando no se consigue mucho. Ni siquiera usando el botón apenas se encienda el aparato pasa algo: esto es malo, ya que el hacer esto usualmente nos da acceso a un sistema de recuperación que nos permite cargar firmware.

    Eso significa que, en el caso de reinstalar el sistema operativo, debo hacerlo de la forma difícil.

    Esta es la parte trasera de la placa — el único chip que destaca es un Spansion FL032PIF. Esta es la memoria flash del aparato, tiene 4 MB de capacidad y el sistema operativo completo está acá dentro. El firmware de TP-Link está basado en Linux, y sí, hay un Linux dentro de esos 4 MB. Quizás la versión 2.6.32, recuerdo alguna vez haberlo visto en otro momento.

    Debemos manipular directamente ese chip si queremos resolver el problema. Todo esto asumiendo que ningún otro componente del router esté quemado o dañado 😅

    Más memoria flash

    Mi intención no solo es rescatar la placa, eso sirve para tener esto funcionando como un router, y los que me conocen saben que tengo más de una docena de estos para jugar. No me serviría tener uno más, y bien podemos jugar a probar otro software para demostrar lo flexible que es esto con sus 400MHz de CPU y 32 MB de RAM.

    Para esto necesitamos un Linux moderno. Y esto nos exige más memoria flash. Hay toooda una historia detrás de esto, pero en OpenWrt se tuvieron discusiones muy largas y extendidas sobre qué hacer cuando 4 MB no sean suficientes. Hubieron peleas incluso entre core devs en el proyecto, pero al final el soporte para estos aparatos se puso como obsoleto y se previene a la gente no comprarlos más.

    Entonces necesitamos más memoria flash, no solo para este router que quizás funcione o no, sino para otros modelos similares que tengo, casi todos TP-LINKs antiguos que también han quedado afectados.

    Reciclaje

    Hace poco se me había ocurrido una idea:

    Esto es un router de fibra. Se fabrican en masa en China y son de marca blanca. Cuando un pequeño ISP (proveedor de Internet) quiere ofrecer el servicio, compra al por mayor esta cosa y les da uno a sus clientes.

    Como estos son de pésima calidad, no tardan en arruinarse y luego se venden como chatarra por mayor, o incluso por kilo si tienes suerte. Me compré como una docena de esos: estaban a 5 Bs en la feria cada uno y me regalaron uno más, en total 13.

    Si vemos en detalle, estos routers vienen con esto:

    Este es un Winbond 25Q128BV: una memoria flash de 16 MB (128 Mb * (1 MB / 8 Mb)).

    Podré desoldarles la memoria a estos routers quemados, flashearlos con un programador SPI (un Raspberry Pi sirve también) y soldarlos en los routers que sí me sirven. Y así poder tener Linux moderno.

    Este es el chip luego de ser extraído:

    También extraeré el chip antiguo de 4 MB. Lo pondré en mi programador SPI para sacarme una copia de lo que sea que tenga:

    sudo flashrom -p ch341a_spi -r mr3020-ac3ed1-fulldump.bin

    Linux Moderno

    Vamos a usar OpenWrt. La meta es que el sistema al menos pueda arrancar, y ahora que tenemos nuestros 16M de flash, debemos compilar nuestra versión de OpenWrt que sea compatible.

    Mis cambios están listos, y el commit de git con los cambios es este:

    https://github.com/LuisMitaHL/LooperWrt/commit/23ac0330531796dc1c515675eb54334a3bb80ffd

    ¿Por qué estos cambios?

    En casi cualquier dispositivo que no sea x86 como una PC o laptop, no existe un BIOS/UEFI que prepare tu máquina, sino que Linux debe conocer todo tu hardware de antemano y «hardcodearlo».

    De fábrica TP-Link deja sus routers con estas particiones:

    • u-boot (un bootloader, algo parecido a un «BIOS» muy sencillo y simple)
    • firmware (el Linux en si)
    • art (binario que calibra la interfaz Wi-Fi)

    Se puede notar en el commit que tuve que hacer un cálculo en hexadecimal: antes tenía 0x400000 (4 MB) de capacidad y ahora tengo 0x1000000 (16 MB). Por tanto, u-boot y art deben continuar con la capacidad usual (0x20000 = 128KB y 0x10000 = 64 KB respectivamente) y asignarle el espacio restante a mi firmware Linux.

    Recordemos que hice un backup del chip de 4 MB. De acá, con el comando dd, puedo partir este backup en las particiones adecuadas. Por ejemplo, el u-boot original de TP-Link lo puedo sacar así:

    dd if=mr3020-ac3ed1-fulldump.bin of=u-boot.bin bs=1 skip=$((0x000000000000)) count=$((0x000000020000))

    No usaré eso en esta ocasión. Aprovecharé en instalar https://github.com/pepe2k/u-boot_mod: es una versión mejorada, incluye sistema de recuperación usando botones que estoy seguro me salvará la vida luego.

    Nos vemos en un siguiente post, para ver cómo está yendo la instalación. Mientras les dejo una foto del router ya (más o menos) vivo, siendo controlado por su interfaz serial.

  • Mi módem portátil fue un teléfono en otra vida

    Lo normal para tener conectividad hacia Internet fuera de casa es usar los teléfonos directamente o creando un Punto de acceso Wi-Fi. Pero más de una vez me dieron problemas: las VPNs se cortan, el ping falla, etc.

    Creo que varios de estos problemas son QoS en las antenas: por ejemplo, en una radiobase saturada, darán prioridad a tráfico de voz primero, quizás descargas luego, etc. De ahí que tráfico de VPNs (que van por UDP) son bastante limitados.

    Lo curioso es que, de todos los teléfonos con los que pude probar, quien fue el más estable con diferencia fue uno Huawei. Funcionaba muy bien y no perdía pings, incluso cuando viajaba en bus 🙂

    De ahí que, hace unos años compré un HUAWEI E5576.

    Desarmándolo

    Luego de ver que funciona muy bien y de llevarlo conmigo un buen tiempo, tal como todo lo que tengo, eventualmente será desarmado.

    Aunque en retrospectiva puede ser algo obvio, me sorprendió ver que la forma del router se asemejaba a la de un celular (!)

    Cuando imaginaba un router móvil, siempre lo pensaba así:

    Diseño de Router

    1. Chip de Router (ejemplo, un Atheros o Mediatek) con un CPU, encargado además de los periféricos y del Wi-Fi.
    2. Conexión a un módem por USB o PCI.

    Este router móvil no sigue esto, y en cambio tiene:

    Diseño de Teléfono

    1. Chip de Teléfono. Este tiene un SoC Balong (apenas encontré información de esto) que viene con el módem 4G integrado.
    2. Chip de Wi-Fi.

    Implicaciones en el rendimiento

    El Wi-Fi integrado era lento y algo sensible al ruido. Además, si conectabas más de 8 cosas, sufría desconexiones al azar.

    Lo malo del Diseño de Teléfono es que los chips Wi-Fi son de… teléfonos. Estos son muy pequeños y tienen que traer lo justo necesario. Y casi siempre se usan para conectarse a una red, no para emitir Wi-Fi.

    Por tanto, el modo Punto de Acceso es muy limitado y tiene mucho menos testeo o pruebas detrás.

    Esa es la razón porque, si creas un Punto de Acceso con tu teléfono, se pone lento si conectas más de 4 cosas. También es por eso que el Wi-Fi integrado del Raspberry Pi es tan malo, en comparación a otros chips de laptops o routers, y no se recomienda armar tu router con uno.

    Por suerte el puerto USB expone una interfaz RNDIS, asi que con cdc_ether en Linux podemos conectarnos de forma cableada y con más estabilidad.

    Rendimiento

    Con la experiencia que tuve con el Huawei anterior, pensé que un módem de la misma marca debe ser bueno. En general si fue así, pero el teléfono tiene LTE Cat12 (600/150) y el módem Wi-Fi es LTE Cat4 (150/50), siendo este último más lento.

    Por desgracia no pude ver algún router móvil, módem Wi-Fi o USB que sea mejor que el Cat4. No es que sea esencial (las velocidades en Bolivia no impresionan mucho), pero sería un buen nice to have.

  • Pasankalla Gratis: la historia del proyecto

    Hola! Esta vez conversaremos sobre la Pasankalla Gratis: el proyecto de red Wi-Fi libre que, si estás en la UMSA, quizás hayas llegado a ver o a usar.

    Estaba escribiendo información sobre el proyecto en la wiki del r00thouse, pero la historia creo que queda mejor en mi blog.

    Versión 1: Módem HUAWEI

    El módem.
    Luis y Rodrigo en St. de Llallagua para LaOtraRed (2022)

    La primera versión nace con un módem 4G en 2022: en las épocas donde Entel ofrecía paquetes ilimitados sin restricciones de velocidad, se abrió el Wi-Fi del módem para que quien lo necesite pueda usarlo. El nombre viene de un viaje con el proyecto LaOtraRed, donde le pusimos el nombre a la red viajando en el minibús y comiendo pasankallas que habíamos comprado en la parada.

    Unas semanas después, aprovechando que compré un paquete mensual se decidió mantener la red abierta para las clases de verano en la Carrera de Informática, donde el internet existente en el sótano era de mala calidad.

    Versión 2: Módem y un MR3040

    El módem Huawei es bueno en recepción 4G (lo compré para otro proyecto justo buscando eso y funcionó súper bien), pero el chip Wi-Fi deja mucho que desear y es muy inestable (si se conectan más de 6 usuarios ya empieza a sufrir cortes).

    El TP-LINK MR3040.

    Desarmándolo, se ve que el módem se parece mucho a un celular sin pantalla :v y esos chips Wi-Fi móviles que traen están optimizados para ser clientes, y no APs, asi que es de esperarse que sea malo emitiendo una red. Por eso llegó el TP-LINK MR3040.

    Conecté el módem al router por USB y este router ya emitía la señal Wi-Fi abierta. Con OpenWrt ya podía ofrecer un mejor servicio, ya que los drivers estaban más optimizados y eran de mejor calidad. De paso, tenía todas las ventajas usuales de OpenWrt: múltiples redes, múltiples señales de Wi-Fi, iptables avanzado, etc.

    Versión 3: Raspberry Pi Zero

    Cuando ya había más gente conectada, y no vi conveniente comprar más paquetes ilimitados por mes (ya venían con un límite de 1.5GB de tráfico al día y además eran más caros), se cambió la estrategia.

    Les presento: la Pasankalla Raspberry.

    Presentada públicamente en la Feria de Grupos de Estudio del 2023, ahora el internet venía de parte de la red de la UMSA. Esta red no tenía una amplia cobertura y junto a algunos posibles fallos de diseño, no era atractiva el usarla directamente.

    Una Raspberry Pi Zero mas un receptor TP-LINK Archer T2U Plus hacían el trabajo. El chipset Wi-Fi del receptor era un Realtek RTL8821AU, y el Wi-Fi Broadcom integrado de la Raspberry Pi hacía el trabajo de hotspot.

    El receptor Realtek hizo un buen trabajo junto a los drivers no oficiales de morrownr. Eché en falta OpenWrt la verdad (los drivers no eran compatibles), y pues en Raspberry Pi OS tuve que configurar cosas como hostapd a mano. Probé RaspAP, tampoco me gustó mucho, no lo vi prolijo.

    ¿Recuerdas que comenté que los chips Wi-Fi móviles se crearon pensando en ser clientes de una red, y no son buenos emitiendo una propia? Esto es un problema que se repite con la Raspberry Pi: el Broadcom BCM43438 tenía una buena señal, pero tenía problemas serios con más de 10 clientes.
    Sé que se podía resolver cambiando o buscando firmware alternativo de Cypress (nueva dueña de la división Wi-Fi y Bluetooth móvil que era de Broadcom), pero no era compatible con cualquier RPi,y te arriesgabas a romper otras cosas.

    Otro problema molesto era el de los canales Wi-Fi: las antenas de la UMSA funcionan configuradas con United States como país. Esto hacía que mi red en el canal 13 (más libre) se bloqueara, ya que el sistema operativo de la Raspberry obedecía esa configuración (incorrecta) del país, y en EEUU el canal 13 está bloqueado.
    Como además el chip malo Broadcom no soportaba canales automáticos (ACS), pues las Pasankallas a veces estaban en un canal Wi-Fi muy ruidoso y el servicio era muy lento.

    Como bonus: el consumo de energía era muy bajo, recuerdo que iba por los 0,20A en 5V.

    Versión 4: Pi Zero + T4UHP

    Ya pasaba Mayo de 2023. Cambié el receptor por un TP-LINK Archer T4UHP. Al llegar a casa vi que el chipset ahora fue un Realtek RTL8812AU, así que tenía que seguir sin OpenWrt 🙁 y debía conformarme con un driver externo. Al menos el driver de morrownr funcionó muy bien y fue muy estable.

    Lo que me animó al cambio fueron las dos antenas. Antes, con una sola antena, me di cuenta que teniendo las Pasankallas horizontales o verticales en la mochila la calidad de la recepción variaba mucho.
    Ahora, con dos antenas, podía tener una horizontal y la otra vertical, y los firmwares compensaban la diferencia de señal, estando yo libre de hacer trabajo manual «apuntando».

    Estaba algo escéptico, pero la diferencia fue muy importante y en mi opinión valió la pena la compra.

    Versión 5: Pi 3 + T4UHP + WT3020 + Nueva caja

    La red de la UMSA es interesante: el internet puede ser lento y malo, pero la conexión interna es buena. DTIC hizo un buen trabajo desplegando GPON por la ciudad (fibra) y con algunas utilidades podías conseguir enrutar tu tráfico por otros routers, teniendo así más velocidad.

    Esto ya hizo necesario el usar otro Raspberry Pi: el Zero se estaba quedando corto y migré al Raspberry Pi 3B. Era lo que tenía a mano, y aunque consumía un tanto más de energía (que no me gustaba) ahora había potencia para llegar hasta 80 Mbps de puro Internet en los dos primeros pisos en la carrera.

    Naturalmente el ancho de banda obtenido lo liberábamos gratis para todos con la Pasankalla. Como el Wi-Fi integrado del Raspberry Pi seguía siendo uno malo, ahora se unió el Nexx WT3020 como emisor hotspot.

    El WT3020 es uno de mis minirouters favoritos. Muy barato en eBay, soporta OpenWrt tranquilamente y tenía buen espacio para software adicional (al contrario que los TP-Links). El chip principal era un MediaTek MT7620, y aunque no era el mejor, era suficiente para el trabajo.

    Internamente tenía dos antenas, así que las ventajas que yo recibía con el receptor las podía dar a los demás, teniendo los clientes de la Pasankalla el doble de velocidad y una mejor cobertura (asumiendo que su receptor sea igual 2×2).

    Versión 6: Pi 3 + T4UHP + WT3020 + Nueva caja y batería

    La batería, una Philips de 10400mAh ya estaba muy vieja y apenas podía con una jornada de clases. Como también estaba agarrando algo de fama underground, se lo continuó tuneando.

    —

    Esta caja acerca más el concepto de la Pasankalla a otro proyecto: el del MiniDatacenter. Con una batería Xiaomi de 20000 mAh, se tiene energía como para conectar una RPi 4 mas sus routers, y así tener servicios locales al alcance de la pequeña maletita.

    Cuando no se hacían labores de MiniDatacenter, estas funcionaban como Pasankalla, alimentando por casi todo un día las antenas y el RPi3.

    Mención honorífica: Confiabits MT7981

    Gracias a la amable donación de Confiabits, disponemos de un router de alta calidad, siendo el primer router Wi-Fi 6 con el que podemos experimentar.

    El router, que viene con un MediaTek MT7981 + radios DBDC MediaTek MT7976C compatibles con Wi-Fi 6, es muy bueno para dar el servicio a muuucha gente! Lo usamos en la Feria de Grupos de Estudio del 2024, además de otros eventos, y si teníamos acceso a energía eléctrica AC, las Pasankallas eran servidas por este router.

    Solo lo hemos llegado a usar en eventos grandes, y no es permanente.

    Versión 7: Cudy TR3000 / Cudy TR1200

    Al momento (mediados de 2024) esta es la última versión, actualmente lo usamos en producción.

    El TR3000 tiene la gran ventaja de ser Wi-Fi 6 también, y el poderse alimentar de forma portable con USB 3 lo hizo un gran sucesor de los Raspberrys. Como este router tiene también un ARM con dos cores mas aceleración por hardware ASIC, ya no hay inconvenientes para manejar Gigabit si fuera necesario.

    El router no era compatible con OpenWrt, asi que se tuvo que hacer el trabajo de desarmarlo, hackearlo y portarlo a Linux (envié la contribución a OpenWrt y ahora gente de todo el mundo puede usar el router con Linux).

    A parte de algunas dificultades, al final se pudo hacer y ya podíamos dar el servicio con mucha mejor calidad. O sea, las Pasankallas ahora son dual-band, funcionando en 2.4GHz y 5GHz. Esto es importante: todas las anteriores versiones emitían solo en 2.4GHz, en canales muy saturados y llenos de ruido. Migrando a 5GHz tenemos canales más vacíos y que soportan mayor densidad de usuarios, mejorando mucho la estabilidad.

    También, ahora no necesitamos la caja, y acomodando el router y la batería ya podemos reducir el espacio y el peso en la mochila.

    El migrar a chips más modernos como el MT7981 tiene sus beneficios. Entre ellos, ahora tenemos soporte 802.11w acelerado por hardware (que no hay en el WT3020). Gracias a esto, ahora la Pasankalla soporta WPA3 con OWE: la red es más segura de usar y resiste hackeos incluso como red abierta, sin contraseña.

  • ¿NGINX y TLS 1.3? Aún no puedes elegir tu cifrado preferido (y quizás nunca puedas)

    NGINX and TLS 1.3? You still can’t choose your preferred cipher (and you may never be able to)

    Ayer estuve haciendo mejoras al servicio de distribución de contenido de LaOtraRed. Estos servidores basados en distintas variantes de Raspberry Pi no tienen aceleración AES, y como estos deben hacer la terminación TLS, quise hacer pruebas con ChaCha20 como cifrado.

    Haciendo pruebas con cURL, en TLSv1.2 va bien (SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305), pero si intento con TLS 1.3…

    SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384

    No importa cómo ajuste ssl_ciphers en Nginx, no funciona. Parece que, como en TLS 1.3 se manejan combinaciones de algoritmos en vez de códigos por combinación, la forma de especificar algoritmos tradicional excluye por defecto a los algoritmos de TLS 1.3 y en OpenSSL han puesto un parchecito creando otro parametro para especificar suites de cifrado para TLS 1.3. Uno que Nginx no quiere soportar.

    Aún tengo pendiente probar la configuración mediante openssl.cnf.

  • SSDs baratos – El Inicio

    Necesitaba unidades SSD para un experimento en mi minidatacenter. Podría ir a la Uyustus a comprarlos, o podía arriesgarme a comprarlas de Internet al precio más bajo…

    Introducción

    Recientemente (2019+) estuve trabajando en Raspberry Pi como servidores. Esto no es estrictamente una novedad: a la gente que le interesaría tener servicios interesantes 24×7 alojados en su casa y no en Internet, les sería mejor tener algo pequeño y que consuma menos energía en comparación a una máquina x86 vieja (que es lo que la mayoría de hackers suele hacer).

    Necesitaba hacer pruebas con una placa con almacenamiento propio, y luego de pensarlo varias veces me decidí por un SSD ya que solo le vi ventajas: menos temperatura, menor consumo eléctrico, etc. Claro que tendría una menor capacidad de almacenamiento disponible, pero no era algo importante por ahora.

    Yo había tenido experiencias ya con SSDs: hace varios meses compré varios para mi laptop y las máquinas de mi casa. Ver cómo funcionan los SSDs, conocer las características internas de su funcionamiento es algo que me produce mucha curiosidad y luego de ver el video de Linus Tech Tips sobre el tema pues decidí ir a AliExpress y buscar la unidad más barata.

    Como comparación, las SSD de 120 GB en las tiendas de la ciudad costaban en esa época cerca de 30 dólares.

    Lo compré en mediados de enero de este año, y lo recibí hace unos días, en Mayo.

    Cómo llegó

    No tengo las fotos del paquete (deseché todo el envoltorio externo por precaución contra el coronavirus), pero la unidad SSD tenía muy poca protección. Un trozo pequeño del clásico relleno de burbuja rodeaba a la unidad SSD, que estaba dentro de una bolsa antiestática oscura sellada al vacío.

    Ya abierta esta, podemos ver la unidad:

    Decido desarmarla, sería genial ver qué hay adentro. La unidad no tiene ni siquiera tornillos: el plástico en la base tiene algunas piezas que hacen de gancho, con un destornillador plano se puede separarlas con facilidad.

    Hay una mejor foto de los componentes, y descubrí algunas cosas interesantes que les comento luego.

    Y ahí dejo una foto de la parte trasera de la placa, como se ve no hay nada interesante.

    Pruebas

    Luego de formatear la unidad a ext4 + hacerle TRIM, la primera prueba fue sencilla: usé un script para medir la velocidad. Suelo usar iozone pero usé esto esta vez, que hace una prueba de escritura y lectura simultánea.

    25MB/s de escrituras aleatorias van muy bien para mi propósito 🙂

    Luego le hice un test extendido de SMART (tardó 15 minutos y dio todo OK). No guardé la captura de los datos SMART, pero me acuerdo que tenía marcada 1 hora en Power_on_Hours, y el valor en Total_LBAs_Written y Total_LBAs_Read iba por los 2000. Me imagino datos que reflejan que se le hizo una prueba al SSD antes de ser vendido.

    Ya pasados unos días, les dejo la información de SMART del disco:

    smartctl 7.1 2019-12-30 r5022 [aarch64-linux-5.4.0-1011-raspi] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     SSD 120GB
Serial Number:    SCRW19121901B0016
Firmware Version: S1120A0
User Capacity:    120,034,123,776 bytes [120 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-3 T13/2161-D revision 4
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue May 26 07:15:07 2020 -04
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever 
                                        been run.
Total time to complete Offline 
data collection:                (  120) seconds.
Offline data collection
capabilities:                    (0x11) SMART execute Offline immediate.
                                        No Auto Offline data collection support.
                                        Suspend Offline collection upon new
                                        command.
                                        No Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        No Selective Self-test supported.
SMART capabilities:            (0x0002) Does not save SMART data before
                                        entering power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        (  10) minutes.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x0032   100   100   050    Old_age   Always       -       0
  5 Reallocated_Sector_Ct   0x0032   100   100   050    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   050    Old_age   Always       -       71
 12 Power_Cycle_Count       0x0032   100   100   050    Old_age   Always       -       25
160 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       0
161 Unknown_Attribute       0x0033   100   100   050    Pre-fail  Always       -       100
163 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       152
164 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       1350
165 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       13
166 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       1
167 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       3
168 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       1500
169 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       100
175 Program_Fail_Count_Chip 0x0032   100   100   050    Old_age   Always       -       0
176 Erase_Fail_Count_Chip   0x0032   100   100   050    Old_age   Always       -       0
177 Wear_Leveling_Count     0x0032   100   100   050    Old_age   Always       -       0
178 Used_Rsvd_Blk_Cnt_Chip  0x0032   100   100   050    Old_age   Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   050    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   050    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   050    Old_age   Always       -       18
194 Temperature_Celsius     0x0022   100   100   050    Old_age   Always       -       40
195 Hardware_ECC_Recovered  0x0032   100   100   050    Old_age   Always       -       602
196 Reallocated_Event_Count 0x0032   100   100   050    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   050    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0032   100   100   050    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x0032   100   100   050    Old_age   Always       -       0
232 Available_Reservd_Space 0x0032   100   100   050    Old_age   Always       -       100
241 Total_LBAs_Written      0x0030   100   100   050    Old_age   Offline      -       4460
242 Total_LBAs_Read         0x0030   100   100   050    Old_age   Offline      -       4674
245 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       3240

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%         1         -

Selective Self-tests/Logging not supported

    Algo curioso: Temperature_Celsius está siempre a 40 grados. Nunca sube, nunca baja.

    Detalles interesantes

    Tal como se vio en los videos que tratan el tema (…), algunas fuentes sugieren el por qué de los precios tan bajos de estas unidades:

    1. La placa está reciclada y el controlador reseteado.
    2. Componentes robados
    3. Componentes que no pasaron el control de calidad.

    El controlador es un SiliconMotion SM2259XT y las memorias son Intel/Micron 29F04T2ANCQJ1. Sobre esta última hay bastante información conflictiva, pero personalmente me inclino a creer que las memorias son 3D QLC de 128 GB cada uno. Sumando las dos que vimos en la placa, serían 256 GB.

    En ese caso podría inclinarme por la tercera opción, quizás estas memorias son demasiado malas para guardar 256 GB de datos asi que le dijeron al controlador que solo guarde 120 GB y esperar lo mejor del algoritmo de corrección de errores (ECC).

    Lo que ahora viene

    La mayoría de reviews en sitios como Aliexpress y Ebay no ayudan mucho: leyendo con atención, la mayoría solo comenta si le llegó el paquete y si la SSD funciona, además de la ocasional prueba de velocidad. Muy raras veces hay comentarios sobre cómo fue la vida de estas unidades: cuántos meses duraron, cuántos datos se escribieron y leyeron en la unidad, etc.

    Las pruebas de velocidad también no son un indicador fiable: una unidad SSD QLC puede llegar hasta ~100MB/s de rendimiento de escritura secuencial (es más lento que un HDD común de 7200 rpm), pero en las pruebas donde se llega hasta 400MB/s muy probablemente el controlador esté usando una caché SLC dentro de las memorias NAND.

    Para mis propósitos va muy bien, crear máquinas virtuales y contenedores en una Raspberry Pi 4 almacenadas en esta SSD. Uso ZFS como sistema de archivos, y como este me permite hacer copias incrementales en otra parte, si configuro un cron para que haga copias de vez en cuando pues no importa si el SSD decide morirse un día 🙂

    Si hay novedades respecto a este SSD las comento en otra entrada en el blog.

  • Cómo instalé Ubuntu Server 20.04 sin ISOs y con muy poca RAM

    Ayer, jueves 23 de abril de 2020 se ha lanzado la nueva versión de Ubuntu 20.04 LTS. Yo estaba esperando esta versión por varias cosas:

    • Soporte de 5 años (el soporte de versiones anteriores es de 3)
    • Módulo Wireguard integrado en el kernel 5.4 y también con soporte oficial
    • Livepatch para todo lo anterior

    Se ve muy bien para instalar en una máquina virtual donde el uptime sea importante, y había agendado instalar esa versión en un VPS importante. Como su tarea básicamente es enrutar paquetes, lo compré con un buen ancho de banda asignado y con poca RAM (512 MB) para ahorrar dinero. Luego de hacer una copia de seguridad a las cosas importantes y montar la ISO de Ubuntu Server, llegué a este kernel panic:

    Analizando el mensaje de error, podemos ver que el init no pudo ejecutarse (error code 2 = ENOENT = no existe el archivo). Los mensajes arriba muestran que el initramfs (mini sistema de archivos comprimido que se descomprime en la RAM para luego ser ejecutado) no pudo descomprimirse. El error más común es grabar mal un disco (devolvería algo como I/O error), pero como estoy usando un ISO con sha256sum verificado, me hace estar más atento al error final: «Write error».

    La instalación de Ubuntu Server ahora es más «live»: se ha dejado de utilizar por completo debian-installer para dar paso a Subiquiti, su nuevo instalador. Quizás el problema sea en la memoria RAM, y resultó que sí.

    Asi que nos toca instalar el sistema operativo de otra manera.

    Revisando el entorno

    Usé btrfs como el sistema de archivos de la raíz para aprovechar la compresión transparente con compress=zstd. Esto nos ayudará: btrfs soporta subvolúmenes y con eso podemos trabajar sin necesidad de particionar.

    El entorno original es Ubuntu 18.04: ya que no necesitaremos particionar, podemos usar el mismo entorno Linux para levantar otro.

    Instalando

    Necesitamos una «partición»

    Sin preveer nada, yo instalé el viejo Ubuntu en la raíz de la partición btrfs. Necesitaré un nuevo subvolumen:

    sudo btrfs sub create /ubuntu2004

    Esta operación crea el subvolumen ubuntu2004 al inicio del montaje actual (/) y podré usarlo como si fuera una partición independiente, ahorrándome muchas horas en particionar o hacer copias. Cabe aclarar que yo usé el instalador oficial antiguo, y eso me da certeza que mi / no está ya en un subvolumen (si eso sucede no es malo de por sí, solo que no quedaría bien organizado).

    Ahora montaré mi subvolumen en una carpeta cualquiera:

    sudo mount -o compress=zstd,subvol=ubuntu2004 /dev/vda3 /mnt2

    Instalamos Ubuntu

    La utilidad debootstrap nos permite desplegar una distribución GNU/Linux basada en Debian usando solo los paquetes de los repositorios: una solución segura y elegante.

    sudo debootstrap --arch amd64 focal /mnt2 http://us.archive.ubuntu.com/ubuntu

    Luego de que haya terminado, ingresaré a esa nueva instalación.

    sudo mount --bind /dev /mnt2/dev
sudo mount --bind /proc /mnt2/proc
sudo mount --bind /sys /mnt2/sys
sudo chroot /mnt2

    Tenemos ya acceso a una instalación funcional, pero a un estilo contenedor. Necesitamos más paquetes para que esta instalación pueda funcionar por sí sola:

    apt install linux-image-generic grub-pc ssh nano

    Ahora configuramos la red:

    nano /etc/netplan/10-internet.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: no
      addresses:
        - x.x.x.x/24
        - "y:y:y:y::y/60"
      gateway4: x.x.x.x
      gateway6: "x:x:x::x"
      nameservers:
        addresses: [x.x.x.x, y.y.y.y]

    El nombre del host ya debería estar en /etc/hostname. Puedes cambiarlo si quieres.

    Luego, agregué el hostname en /etc/hosts para mantener al comando sudo al tanto:

    echo "127.0.1.1 $(hostname)" > /etc/hosts

    Adapto la configuración regional para activar es_BO.UTF-8 y mi zona horaria:

    dpkg-reconfigure locales
timedatectl set-timezone America/La_Paz

    Necesito que la instalación se acuerde de su partición raíz:

    nano /etc/fstab

UUID=6b02ed42-d91f-48a5-85af-d3d5cba35be7       /       btrfs   rw,compress=zstd,subvol=ubuntu2004      0     2

    Y, finalmente, necesito agregar un usuario y adicionarlo a grupos relevantes. El grupo sudo me da poderes de superusuario y systemd-journal me da acceso al registro completo de sucesos del sistema.

    adduser elusuario
adduser elusuario sudo
adduser elusuario systemd-journal

    Antes de reiniciar, me aseguro de que el sistema es arrancable:

    update-grub
grub-install --recheck /dev/vda

    Y eso es todo. Ya tengo una instalación rápida y limpia de Ubuntu 20.04 sin utilizar la ISO, ni reparticionar, ni nada.

    Algunos comentarios

    Yo había utilizado dos particiones: una ext4 para /boot y otra btrfs para el /: la versión de grub que venía en Ubuntu 18.04 no soportaba compresión zstd, y el sistema quedaba sin poder arrancar, a menos que ponga el kernel y otras cosas importantes en ext4. Ahora Ubuntu 20.04 viene con grub 2.04, que sí tiene soporte y me permite tener todo en un solo subvolumen.

    Ah, sí, ahora update-grub (o bueno, grub-mkconfig y os-prober) ya reconoce instalaciones distintas de GNU/Linux separadas en subvolúmenes, lo cual nos ahorra mucho trabajo en configurarlo.

  • RIPE Atlas, o el cómo monitorear todos los rincones de Internet

    En uno de los grupos de Telegram en los que estoy, estaban buscando voluntarios para «RIPE Atlas». Fui, me dieron un aparato para que lo conecte a mi red, y estuve revisando el proyecto para ver de qué trataba. Aquí escribo lo que entendí.

    RIPE Atlas es un proyecto de RIPE NCC que busca ser una de las plataformas de monitoreo y medición de parámetros de red e Internet a nivel mundial.

    Cómo y para qué funciona

    RIPE Atlas se conforma principalmente de pequeños aparatos llamados sondas («probes» en inglés), y los voluntarios las instalan en su red.


    Esta foto la tomaron los responsables de RIPE Atlas Bolivia cuando el primer envío llegó y empezaron a buscar voluntarios. Casualmente esa sonda me la llevé yo.

    Su propósito es llegar a entender las diferentes redes de las que Internet se conforma, y poder hacer mediciones desde ellas. Las sondas a nivel mundial exponen al panel de control central de RIPE Atlas las siguientes mediciones: ping, traceroute, DNS, NTP, HTTP/HTTPS. Así, investigadores de todo el mundo pueden obtener estas medidas, entre otras cosas:

    • Revisión del routing entre redes e identificacion de problemas. Por ejemplo: descubrimos que en Bolivia, la red de la Univ. Mayor de San Andrés, filtra paquetes locales al exterior del país.
    • Detección regional de firewalls L7 o bloqueos por censura.
    • Revisión del efecto en Internet de las peleas entre ISPs (peering u otra cosa).
    • Comprobación de la eficiencia de un CDN
    • Registro fiable de caídas regionales del servicio de Internet


    Una sonda de RIPE Atlas consume muy poco ancho de banda.

    Cabe aclarar que las mediciones de RIPE Atlas no involucran calidad de servicio y/o velocidad de conexión [1].

    Solicitar una sonda

    Es posible apoyar al proyecto solicitando gratuitamente una sonda Atlas directamente a RIPE NCC, o comunicarse a una organización local que las haya pedido (RIPE Atlas Bolivia, por ejemplo). RIPE NCC espera algunas cosas de los que se ofrezcan a mantener una sonda:

    • Se asume que la sonda se va a colocar de forma fija en la casa (probablemente al lado del router) y que se quedará funcionando por tiempo indefinido.
      • Si uno ya no puede seguir manteniendo la sonda, es posible transferirla a otro interesado.
    • La sonda debe tener una conexión permanente a Internet. Como consume muy poco datos, no importa si es ilimitada o no.
    • La sonda sigue siendo propiedad de RIPE NCC (es decir, no es un regalo).
    • La sonda será monitoreada continuamente desde el exterior, y dependiendo de cómo se la instale, los datos de tu red (como tu IP externa) serán públicos.
    • La sonda tendrá actividad remota DNS y HTTP/HTTPS dentro de tu red, y puede que tu ISP relacione esa actividad contigo. De todas maneras, RIPE Atlas supervisa las pruebas que se transmiten a las sondas a nivel mundial.
    • La sonda viene con un firmware especial cerrado, que se administra mediante un servicio web online. La red a la que se debe conectar debe soportar obligatoriamente DHCP.
    • Un envío de una sonda consiste en: 1) una sonda Atlas V3 (un router TP-LINK TL-MR3020 con firmware especial), 2) un cable de red y uno USB para energía. La alimentacion eléctrica, como adaptadores y etc., es responsabilidad del usuario (es decir, hay que tener cuidado para no quemar el aparato usando adaptadores de energía USB de baja calidad)