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

Qué es RIPE Atlas

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

Cómo funciona la Red del proyecto

La Red se conforma principalmente de pequeños aparatos llamados sondas (“probes” en inglés). La gente instala sondas en su casa (conectándolas a su router), donde éste aparato se comunica con los servidores centrales del proyecto, donde son controlados remotamente.

Propósito y utilidad

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 éstas medidas, entre otras cosas:

  • Revisión del routing entre redes e identificacion de problemas (ej: descubrimos que en Bolivia, la red de la Univ. Mayor de San Andrés, por una mala configuración, 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 disputas de peering o peleas entre ISPs.
  • 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: ideal para usuarios con servicio medido, como 4G.

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, 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 completamente 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: la guía definitiva

Hola!

Desde que Ubiquiti haya cerrado la posibilidad de usar firmware alternativo en los aparatos que distribuye (incluso violando la GPL una vez más al distribuir un U-Boot modificado sin 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. Piensa dos veces y guíate por el sentido común antes de hacer pasos peligrosos. 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, AirBean). 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 ésto y ACS no funciona como debe.

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 ciegos y 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 canales y el router escogerá alguno de ellos.

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 no me responsabilizo si te equivocas. Debes seguir los pasos y leer mucha documentación para saber lo que estás haciendo. 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á casi imposible 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/lede-dev@lists.infradead.org/msg06759.html
  • http://lists.infradead.org/pipermail/lede-dev/2017-April/007005.html

Tema Peridot (Steven Universe) para Fruity Dance

Hola, aquí traigo una animación de Peridot para usarla con el plugin Fruity Dance en FL Studio. Se puede utilizarla para “animar” el proyecto, aunque si estás armando una pista con video en vivo y tienes dos monitores (o un proyector, o una pantalla gigante), podría ser aún más útil.

No había ninguna en Internet, así que armé una yo.

GIF animado de Fruity Dance funcionando al ritmo de la música

El tamaño de la animación es el mismo que del tema nativo, FL Chan.

Descarga e Instalación

Puedes descargar el .zip aquí.

Lo mejor es “instalar” el tema de forma fija, extrayendo los archivos del .zip y copiando los dos archivos *.png y *.txt a la dirección C:\Program Files (x86)\Image-Line\FL Studio\Plugins\Fruity\Generators\Fruity Dance\Artwork.

Por otra parte, siempre puedes copiar los dos archivos *.png y *.txt a una carpeta fija cualquiera, arrastrar el .png y llevarlo encima de FL-Chan, si el plugin Fruity Dance ya está cargado y configurado.

 

Error state: check-failed utilizando canonical-livepatch

Hola!

Yo utilizo la versión gratuita de canonical-livepatch para tres servidores dedicados (yo virtualizo, y es incómodo perder uptime en las máquinas virtuales).

Casualmente, al activar el servicio en una máquina (utilizando una plantilla Ubuntu 16.04 de OVH) canonical-livepatch funciona momentáneamente, pero al cabo de unas horas aparece un error en el journal:
Bad server status code: 403. URL: https://livepatch.canonical.com/api/machine/<id> {"error": "Invalid Machine Token"}

y a eso debemos sumar un error de tipo check-failed, que impide seguir bajando actualizaciones del servicio, haciendolo inútil.
maverickp@pearl:~$ sudo canonical-livepatch status --verbose
(...)
status:
- kernel: 4.4.0-45.66-generic
running: true
livepatch:
checkState: check-failed
(...)

Resolviendo el error

Al parecer, la plantilla Ubuntu 16.04 de OVH debería generar sistemas diferentes al usarlo para instalar servidores. Genera los pares de claves para SSH por máquina, entre otras cosas, pero la plantilla viene con un parámetro de systemd llamado machine-id, que es el mismo para todos, pero no deberíamos compartir.

canonical-livepatch utiliza éste campo para crear una pareja única machine-id<=>token, creando así el machine-token para la máquina. Si alguien activa su servicio con tu machine-id, tu machine-token será revocado de inmediato.

Necesitamos obtener nuestro machine-id original:

cat /etc/machine-id
5b4291032856154f1caf5ffb5694cdc3

Luego lo cambiamos por otra cadena aleatoria:

head /dev/urandom | md5sum | cut -d " " -f 1 | sudo tee /etc/machine-id

El manual de systemd tiene una utilidad para generar otro machine-id, pero necesita un rootfs no booteado.
Por ese motivo, nos aseguraremos de reiniciar la máquina ahora mismo, para evitar fallas raras.

Nuevo nodo de la Red Libre en Villa Fátima

Desde hace unos días está funcionando un nuevo nodo en la Red Libre en Villa Fátima, cerca de la Plaza Villarroel. Más concretamente, es el nodo Cherski, operado por Rodrigo Garcia.

Todos los detalles del nodo Cherski están acá (y se actualizan constantemente). Aún no hemos logrado un enlace fijo con el nodo Sopocachi I, pero esperamos que la situación vaya mejorando mientras la Red crece a lo largo de toda La Paz.

Antena del nodo Cherski

 

OpenWrt: ver cuántos clientes (Wi-Fi, ethernet) se conectaron al router

Actualmente manejo un punto Wi-Fi abierto de la red libre La Otra Red, y suele darme curiosidad cuánta gente se ha conectado. Los routers hotspot tienen OpenWrt instalado, y aprovechando DHCP, mediante la interfaz web podemos ver a los clientes que solicitaron direcciones IP (y por lo tanto, se han conectado a la red).

El problema es éste: los registros sólo duran el tiempo que el servidor DHCP le ha asignado la dirección.

Leer másOpenWrt: ver cuántos clientes (Wi-Fi, ethernet) se conectaron al router

Frecuencias Wi-Fi de uso libre en Bolivia

Hola!

Trabajando en el proyecto de Red Libre “La Otra Red”, salió la importancia del tema del uso responsable de las frecuencias Wi-Fi que la Red utiliza.
En uno de mis ratos libres he creado un pequeño diseño imprimible para hojitas en un formato cómodo (de bolsillo) de 10,5cmx6,5cm con toda la información necesaria, para cuando alguien toquetee antenas Wi-Fi, pueda calcular y escoger una frecuencia sabiendo que es legal.

EL diseño lo tengo desde hace meses, pero creo que sera más útil si lo publico.
Los datos se extrajeron del Plan Nacional de Frecuencias, aprobado en 2012.

Vista Previa

freqlibres-page-001-1freqlibres-page-002-1

PDFFrecuenciasLibres.pdf

La licencia es Creative Commons BY-SA 4.0.