Categoría: Post random

  • 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)
  • LEDE 17.01 en un Ubiquiti UniFi AC AP Lite

    Desde que Ubiquiti ha cerrado la posibilidad de usar firmware alternativo en los aparatos que distribuye (incluso teóricamente violando la GPL al distribuir un U-Boot modificado sin su código fuente), se ha vuelto más difícil intentar instalar OpenWrt o LEDE. Pero, gracias a la experiencia obtenida en algunas tareas, he podido armar esta guía para hacerlo (mas una explicación al final). Quizás haya contenido que no necesariamente aplica a tu aparato. De todas maneras, si arruinas el proceso, los routers Ubiquiti te permiten cargar firmware (oficial) por TFTP y así poder volver a empezar. Igualmente, sería bueno que hagas copias de los bloques /dev/mtdblock* en el firmware original y los saques a tu máquina con scp, para estar más protegido, por si acaso.

    Cómo instalar LEDE en el UniFi AC AP Lite

    Necesitamos los siguientes archivos:

    Ahora podemos empezar a trabajar.

    Fase 0: Desbloqueando el firmware

    Por defecto los APs con los que trabajé venían con la versión 3.4.14 del firmware oficial. Como éste ya implementa verificación de las firmas digitales para el firmware de Ubiquiti, tenemos que hacer un downgrade (desactualizar) a la versión 3.4.7, que no implementa ésta restricción.

    1. Enciende el AP y conéctate. Si está ya configurado, debes resetearlo. De preferencia, el router no debe tener acceso a Internet ahora mismo.
    2. Conéctate al servicio ssh de la IP por defecto 192.168.1.20, con las credenciales ubnt/ubnt.
    3. Copia el fichero BZ.qca956x.v3.4.7.3284.150911.1650.bin a la carpeta /tmp del aparato, usando el nuevo nombre fwupdate.bin. Puedes hacerlo con un miniservidor http (python3 -m http.server 8080) o con scp.
    4. Luego de tener ya el archivo /tmp/fwupdate.bin, ejecuta syswrapper.sh upgrade2.
    5. Espera unos minutos a que el router se reinicie.

    Fase 1: Instalando el firmware intermedio

    Ubiquiti usa un formato un poco extraño para el firmware de sus APs, y gracias a éso, no podremos instalar OpenWrt/LEDE así nada más, ya que tratará de ejecutar el firmware desde una partición no esperada. Usaremos un firmware intermedio para corregir éso.

    1. Conéctate al AP por ssh. La vieja IP (192.168.1.20) y las credenciales ubnt/ubnt aún deberían servir.
    2. Copia el archivo lede-r3435-ubnt-unifiac-lite-enmaskarado-phase1.bin a la carpeta /tmp del AP.
    3. Ejecuta:
      1. mtd write /tmp/lede-r3435-ubnt-unifiac-lite-enmaskarado-phase1.bin kernel0
      2. mtd -r write /tmp/lede-r3435-ubnt-unifiac-lite-enmaskarado-phase1.bin kernel1
    4. El aparato se reiniciará, y luego de unos minutos, el firmware de primera fase estará funcionando. Deberías tener acceso por ssh a la IP 192.168.1.1, sin credenciales.
    5. Ejecuta:
      1. insmod mtd-rw i_want_a_brick=1
    6. Ahora todas las particiones se han desbloqueado y habilitado como lectura/escritura. Revisa la estructura del chip SPI, para identificar a la partición bs (que en nuestro caso, está en mtd7). root@n16p1:~# cat /proc/mtd
      dev: size erasesize name
      mtd0: 00060000 00010000 «u-boot»
      mtd1: 00010000 00010000 «u-boot-env»
      mtd2: 00790000 00010000 «firmware»
      mtd3: 00140000 00010000 «kernel»
      mtd4: 00650000 00010000 «rootfs»
      mtd5: 002a0000 00010000 «rootfs_data»
      mtd6: 00790000 00010000 «ubnt-airos»
      mtd7: 00020000 00010000 «bs»
      mtd8: 00040000 00010000 «cfg»
      mtd9: 00010000 00010000 «EEPROM»
    7. Descarga al router el archivo UnifiAcApLite_mtd7_bs_kernel0.bin, en la carpeta /tmp.
    8. Vamos a sobreescribir esta partición bs, quizás quieras tener backups. Ahora ejecuta:
      1. mtd write /tmp/UnifiAcApLite_mtd7_bs_kernel0.bin bs

    Fase 2: Instala el firmware final que desees

    1. No reinicies. Ahora sí, descarga el firmware LEDE que quieras usar (versión sysupgrade), y ejecuta:
      1. sysupgrade -n /tmp/lede-17.01.3-ar71xx-generic-ubnt-unifiac-lite-squashfs-sysupgrade.bin
    2. Si el aparato te pregunta reiniciar, dile que sí. Luego de ésto, ya tendrás LEDE en el AP.
    3. Fin.

    Explicando los pasos

    Ubiquiti maneja una estructura de la memoria en sus APs un poco rara, pero que cada vez es más común en entornos profesionales y alguno doméstico: dos particiones para el firmware. Así, estos aparatos se pueden actualizar automáticamente y de forma masiva, sin riesgos. Si una actualización falla, el antiguo firmware puede ejecutarse de nuevo y minimizar el tiempo de no-actividad del AP. LEDE se conforma bien con tomar la primera partición, pero el proceso de instalación de Ubiquiti no le garantiza que sea así:

    • Por defecto los APs vienen con su firmware en kernel0.
    • Al desactualizar el aparato a la versión 3.4.7, éste firmware se carga en kernel1, y el bootloader de Ubiquiti se configura para bootear éste kernel1, modificando un byte en la partición bs.
    • LEDE espera estar en kernel0.
    • Por eso necesitamos instalar el firmware de fase 1 en ambas particiones:
      • si se copia sólo en kernel0, LEDE nunca se ejecutará.
      • Si se copia en sólo kernel1, LEDE arrancará bien su kernel, pero intentará montar los sistemas de archivos (la base squashfs y el jffs2) desde kernel0, donde obviamente no están: ésto genera un kernel panic, y por consiguiente, un soft brick.
    • Si copiamos nuestro firmware final a ambas particiones, puede funcionar, pero será un caos terrible intentar actualizarlo, etc. Es mejor corregir ésto.
    • Para arreglar éste desastre, copiamos el firmware de fase 1 a ambos bloques y corregimos la partición arrancable del bootloader, flasheando con mtd-rw una partición bs modificada.
    • Así el bootloader arrancará kernel0 y LEDE estará contento. Tareas como el sysupgrade volverán a funcionar.

    Partición bs

    • ¿Qué significa bs? Quizás boot-selector, o algo así.
    • Ésta partición prácticamente no tiene datos propios del AP: en varios AP de un mismo batch, he verificado que no hay diferencias entre particiones bs, y que un sólo bs modificado sirve para todos.
    • El primer byte hexadecimal de la partición bs determina la partición a arrancar: un 0 significa kernel0, y un 8 significa kernel1.
    • Aquí tengo un bs que bootea kernel0 y otro bs que bootea kernel1, por si quieres ver las diferencias de ambos con hexdump.
    • Si estás seguro de que tu AP (sea un AC AP Lite o no) bootea su firmware oficial desde kernel0, puedes copiar su partición bs al principio, y luego restaurarla cuando necesites corregir el orden, teniendo LEDE ya.
  • Restringir canales Wi-Fi para el selector automático (ACS) en LEDE

    Tengo un pequeño aparato Wi-Fi móvil (mi nodo móvil de LaOtraRed, Mochila Hacker). Lo llevo a todas partes, y a veces el canal Wi-Fi en el que está configurado no es el mejor (tiene más interferencia de otros routers, por ejemplo). Usando la función Automatic Channel Selection que hostapd expone, podemos hacer que OpenWrt o LEDE revisen velozmente la banda 2.4GHz y elijan el canal más limpio.

    Como nota adicional, el único controlador inalámbrico que he visto que funciona más o menos bien con ACS es ath9k (con alguno que otro bug, especialmente si usas 2+ interfaces virtuales en LEDE 17.01.2), ya que éste sí tiene cosas como el detector de ruido ambiental en el canal Wi-Fi (noise floor). Los chips Ralink de los aparatos que tengo, no soportan esto y ACS no funciona.

    El problema que me ocasiona es que ésta función tiende a ocupar el canal 13, que casi siempre está vacío, pero no todos los clientes Wi-Fi lo soportan, gracias a clientes y APs mal configurados alrededor (es una historia larga acerca de 802.11d y 802.11h). Gracias a ésto, la gran mayoría de clientes Wi-Fi usa las regulaciones US (de Estados Unidos), y por lo tanto, son sordos a los canales 12 y 13. Podría configurar mi router móvil con las regulaciones en US y así evitar esos dos canales, pero eso significaría contribuir más al desastre de 802.11d en mi ciudad. Configurando la opción country_ie se evitaría, pero sigo creyendo que no es la mejor solución.

    Solucionando el problema

    Resulta que hay una opción no documentada en OpenWrt (desde r47427 de trunk, en noviembre de 2015) y LEDE para poder restringir los canales de los que el ACS puede disponer, llamado el array channels:

    config wifi-device 'radio0'
    #(…)
    option channel 'auto'
    list channels '1'
    list channels '6'
    list channels '11'

    Funciona: puedes probar especificando algunos pocos canales y el router escogerá alguno de ellos.

  • (2017) Trivia Sysadmin I – Alta carga

    Aquí tenemos una captura de un servidor que se ha vuelto loco, ¡con un load average que llega a 136! (demasiado para un servidor con 2c/4t de CPU).

    El reto consiste en analizar esa captura de pantalla y descubrir qué está haciendo el servidor para haber llegado a tal extremo.


    Contexto

    Quiero dar de baja este servidor porque necesito ahorrar dinero. Venía con un disco de 2 TB (si, un solo disco, sin RAID ni nada) que usaba para los backups de mis backups.

    Pistas e indicaciones

    • El load average de 1m/5m/15m debería darte una idea del tiempo que el servidor lleva trabajando así.
    • Los Intel Atom CPU D525 tienen 2 cores y 4 threads, pero aún así, el rendimiento es terrible comparado a otros CPUs de Intel.
    • Uno de los comandos que se ven ejecutándose es vital para entender el problema, pero estrictamente no está generando carga al CPU.
    • Hace unas semanas en el FLISoL dieron una charla de seguridad informática básica muy buena: es sorprendente cómo la gente da por ciertas muchas cosas.
    • La carga del sistema es alta, pero htop dice que los 4 threads de CPU están con poco trabajo.



    Solución

    Estoy sobreescribiendo mi disco duro con ceros, con el comando:

    ~# pv < /dev/zero > /dev/sda.

    El comando pv me da la opción de ver cuánto del disco se ha sobreescrito con ceros y cuánto le falta para completar.
    El proveedor del servidor me ha configurado el disco con ext4 (sistema de archivos que no da la opción de cifrado nativo), no configuré LUKS/dm-crypt y sé que un futuro arrendatario del servidor podría ejecutar utilidades como testdisk o photorec para recuperar contenido que yo hubiera creído ya eliminado.

    El formateo a bajo nivel (llenar de ceros el disco en este caso) es una forma bruta de proteger datos, pero funciona, y los archivos son suficientemente irrecuperables para mi gusto (otras personas recomiendan múltiples pasos para contenido sensible).

    En la orden ~# pv < /dev/zero > /dev/sda el proceso que escribe a /dev/sda depende directamente de la velocidad del disco duro (lento): como no puede igualar los ~1.2GB/s de /dev/zero, el caché de escritura en RAM se llena y se genera mucho I/O Wait (pausas del CPU esperando a que los datos terminen de escribirse en el disco). Además, formatear 2TB a 120MB/s da el tiempo suficiente para disparar el Load Average y llegar a cantidades absurdas.

    Como bonus: htop no muestra el IOWait por defecto. Se puede activar manualmente yendo a sus opciones, o se puede usar top, que sí muestra al menos un porcentaje.

  • LEDE 17.01.1 en una Mikrotik RB750GL, sin brickear nada en el intento

    Hola! Algunos de uds. saben que estoy ayudando a montar una red de Internet en la carrera donde estudio (Informática-UMSA). Entre las compras, venía un RouterBOARD 750GL con instrucciones de instalar OpenWrt para nuestro propósito. Instalar OpenWrt es sencillo (initramfs + wget2nand), pero ésto se ha vuelto más complicado con LEDE, y no sale a la primera. Pero tengo una guía para lograrlo a la primera (necesitarás un sistema GNU/Linux cualquiera, medianamente actualizado).

    Primeros pasos

    • Vamos a tocar el sistema de archivos completo, así que es hora de hacer una copia de tu licencia RouterOS, si quieres volver a ése firmware sin romper nada. Abre WinBox -> System -> License -> Export Key.
    • No debes fiarte de una sola fuente de información, y debes considerar que puedes equivocarte. Para poder ver el panorama con más claridad, debes leer la documentación. TEN MUCHO CUIDADO: aquí es muy fácil romper cosas. Ésta edición de RouterBOOT no habilita los pines serial TX-RX de la placa (y para colmo, la memoria es NAND), así que un hard-brick será muy difícil de solucionar.
    • Igual, debes saber que las RB750GL suelen tener cambios importantes de hardware sin ser mencionados (como el tamaño de la NAND). ¡Mucho ojo con brickear algo!

      Para instalar LEDE, vamos a aprovechar una feature de RouterBOOT y utilizaremos una imagen initramfs que se cargará en la memoria RAM. Para ello, necesitamos configurar al router para que 1) bootee de la red una vez, y 2) que luego bootee de la NAND. Sí o sí necesitaremos WinBox para eso. Volvé a Windows, conecta tu máquina a un puerto LAN cualquiera del router, y abre WinBox.

    1. System → Routerboard → Settings → Boot device: Try ethernet once then NAND
    2. System → Routerboard → Settings → Boot protocol: DHCP
    3. System → Routerboard → Settings → Force Backup Booter: Activar (¡importante!)

    Guarda («save»), y luego, apaga el router. No lo enciendas ahora.  

    Instalando LEDE 1/2

    Ahora, inicia tu sistema GNU/Linux, andá a tu $HOME, creá una carpeta «mtikgl» y una carpeta «mtikglcc» En la carpeta mtikgl descarga éstos archivos:

      En la carpeta mtikglcc descarga éstos archivos:

    Ahora, asigna a tu máquina la dirección 192.168.0.100/24 con iproute2 o con NetworkManager. Luego conecta tu máquina al router, al puerto 1 (WAN): NO LO ENCIENDAS AÚN.  

    Quizás, al encender el router luego, la interfaz se levante demasiado rápido y no te alcance a activar un comando. Tal vez haya flips, y las siguientes instrucciones no funcionen. Para estar seguros, conecta al medio de tu máquina y el router, un switch ethernet barato.

      Ahora abre un terminal en la carpeta mtikgl y ejecuta:

    sudo killall dnsmasq
    sudo dnsmasq --no-daemon --port=0 --dhcp-range="192.168.0.50,192.168.0.150,12h" --enable-tftp \
    --bootp-dynamic --dhcp-boot="lede-17.01.1-ar71xx-mikrotik-vmlinux-initramfs.elf" \
    --tftp-root="$HOME/mtikgl"

    Ahora, toma un palillo y presiona el botón de RESET, con el router apagado. Mientras mantienes presionado RESET, ahora sí enciende el router. Espera al menos 15 segundos, y luego quita el palillo. Podrás ver ahora en las lucecitas del switch bastante actividad, y en la ventana del terminal donde está dnsmasq, que alguien pidió una IP y descargó el initramfs.   Bien! Ahora LEDE está cargándose en la memoria RAM, y puedes cerrar el dnsmasq con un Ctrl-C. Conéctate al router usando cualquier puerto LAN (del 2 al 5) y asígnate la IP 192.168.1.100/24. Ahora nos conectamos al router e instalaremos LEDE.

    # Copiamos ahora mismo el firmware. Aquí uso el firmware para NANDs >=128, ojo.
    scp lede-17.01.1-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin 192.168.1.1:/tmp

    ssh -l root 192.168.1.1
    # ahora estamos dentro del router
    cd /tmp
    sysupgrade lede-17.01.1-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin

      Si todo va bien, el router aceptará el archivo y la sesión SSH se apagará de inmediato. Déjalo así unos 30 segundos.

    Instalando LEDE 2/2

    La instalación debería ser así de fácil, pero no funciona: el router no podrá bootear LEDE y entrará en un bootloop. Al parecer, LEDE ahora guarda el kernel y el rootfs en la partición UBI de datos en mtd3, pero algunas ediciones de RouterBOOT sólo pueden bootear kernels en la partición mtd2, formateada con yaffs. Hasta donde sé, LEDE no soporta ya yaffs.   Gracias a nuestra configuración de RouterOS, el bootloop activa el booteo por DHCP y podremos arrancar otro initramfs. Vamos a la carpeta mtikglcc y ejecutamos ésto:

    sudo killall dnsmasq
    sudo dnsmasq --no-daemon --port=0 --dhcp-range="192.168.0.50,192.168.0.150,12h" --enable-tftp \
    --bootp-dynamic --dhcp-boot="openwrt-ar71xx-mikrotik-vmlinux-initramfs.elf" \
    --tftp-root="$HOME/mtikglcc"

    Nos conectamos con la IP 192.168.0.100/24 al router encendido (que está en bootloop ahora mismo) al puerto 1 (WAN). No suele ser necesario reiniciar, el router debería pedirte un initramfs desde ya.   Ahora, conéctate al router usando cualquier puerto LAN (del 2 al 5) y asígnate la IP 192.168.1.100/24

    # Copiamos el kernel que falta
    scp ../mtikgl/lede-17.01.1-ar71xx-mikrotik-vmlinux-lzma.elf 192.168.1.1:/tmp/

    telnet 192.168.1.1
    # ahora estamos dentro del router
    cd /tmp
    cat /proc/mtd
    # debería aparecer la partición kernel como mtd1

    mtd erase kernel
    mount /dev/mtdblock1 /mnt
    mv /tmp/lede-17.01.1-ar71xx-mikrotik-vmlinux-lzma.elf /mnt/kernel
    chmod a+x /mnt/kernel
    umount /mnt

    Ahora sí puedes reiniciar, y al bootear de nuevo, LEDE debería estar funcionando.  

    Créditos

    He tomado información de los siguentes enlaces:

    • https://wiki.openwrt.org/toh/mikrotik/common
    • https://www.mail-archive.com/[email protected]/msg06759.html
    • http://lists.infradead.org/pipermail/lede-dev/2017-April/007005.html