Categoría: Post random

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:

• http://downloads.lede-project.org/releases/17.01.1/targets/ar71xx/mikrotik/lede-17.01.1-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin (si tu NAND es >= 128 MB, la mayoría lo es)
• http://downloads.lede-project.org/releases/17.01.1/targets/ar71xx/mikrotik/lede-17.01.1-ar71xx-mikrotik-nand-64m-squashfs-sysupgrade.bin (si tu NAND es de 64 MB)
• http://downloads.lede-project.org/releases/17.01.1/targets/ar71xx/mikrotik/lede-17.01.1-ar71xx-mikrotik-vmlinux-initramfs.elf
• http://downloads.lede-project.org/releases/17.01.1/targets/ar71xx/mikrotik/lede-17.01.1-ar71xx-mikrotik-vmlinux-lzma.elf

  En la carpeta mtikglcc descarga éstos archivos:

• http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/mikrotik/openwrt-ar71xx-mikrotik-vmlinux-initramfs.elf

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

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

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"}.

Además aparece otro error de tipo check-failed, que impide seguir bajando actualizaciones del servicio.
sudo canonical-livepatch status --verbose
(...)
status: - kernel: 4.4.0-45.66-generic
running: true
livepatch: checkState: check-failed (...)

Resolviendo el error

La plantilla Ubuntu 16.04 de OVH, a pesar de ser la misma para los clientes, tiene que asegurarse que ciertos datos no sean los mismos. Esta debe generar, por ejemplo, los pares de claves para SSH por máquina. La plantilla viene con un parámetro de systemd llamado machine-id que en teoría debe ser única por máquina y se genera aleatoriamente al momento de la instalación.

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, y como la plantilla de OVH no tomó en cuenta eso, entonces así llegamos a la falla.

Necesitamos obtener nuestro machine-id original para ver que tenemos este fallo: 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.

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.

Hola! En esta ocasión dejo buenas noticias: mi nodo de la red libre La Otra Red, por fin ha entrado en operación!

Características:

• Ubicación: Alto Sopocachi – Av. Jaimes Freyre (cerca al edificio oscuro donde está el SEDEM).
• Cobertura: Al menos 50 metros a la redonda.
• Notas: La señal abierta de la Red Libre puede percibirse desde Alto San Antonio y Pampahasi si se usan receptores USB de alta ganancia. Igual debería haber señal en la línea amarilla del Teleférico, en parte del tramo Tembladerani-Plaza España.

Servicios para la Red Libre

• Wikipedia Libre completa en tres idiomas (español, aymara, quechua)
• Wikis adicionales (Wikisource, Wikiviajes, Wikcionario)
• Looking Glass para diagnósticos de la Red Libre (disponible online)
• El Botadero – Comparte y descarga archivos de todo tipo
• Bloc de notas encriptado (disponible online)
• Koel (Spotify abierto)
• Servicios en pruebas internas:
  • Chat
  • Llamadas y videollamadas gratis a lo largo de la Red Libre
  • Imageboard

En las próximas semanas se harán disponible en la wiki del proyecto las instrucciones para replicar la instalación de estos servicios a lo largo de la Red Libre. Si estás interesado en participar en el proyecto, contáctate con nosotros o pregúntanos algo.

Historia rápida del Nodo

(o el por qué tardé tanto para levantar éste nodo)

• 2015 al 2016 (hasta agosto): nadie se ocupó de su nodo, todos hemos trabajado en el nodo Miraflores (donde se encuentra el Hacklab La Paz)
  • El nodo Miraflores sí fue un caos: la falta de internet (por consiguiente, la imposibilidad de controlar remotamente las máquinas) ocasiona que, para configurar aspectos básicos de un nodo, tardemos semanas y semanas
  • En toda esa fecha los intentos de mi nodo Sopocachi I eran sólo lograr unirse al nodo Miraflores y hacer una «repetidora» de los servicios que ofrezca ese nodo.
• En 2016, al ya darme cuenta de que un enlace directo al Hacklab desde mi casa no era posible, empece a estudiar la posibilidad de abastecer mi nodo con servicios puestos en servidores locales, y así mi poca «experiencia» manejando servidores GNU/Linux podría entrar en juego.
  • Al inicio, sólo tenía una máquina vieja (Pentium 4) que además era terriblemente ruidosa. He experimentado el cómo instalar servicios, pero al fin no pude instalarla de forma fija (esa máquina no dejaba dormir a nadie; además era muuuuy lenta)
    • Para Agosto yo seguía con el problema de la máquina vieja, pero al menos la red interna del nodo había mejorado: había agregado más routers cableados dentro del Nodo, los puntos troncales ya usaban Gigabit y había reacomodado y reparado todos los cables. Aquí puse el progreso de esas tareas.
  • En Septiembre u Octubre, alguien cercano donó un Raspberry Pi 3. De esta manera ya pude continuar (aunque, siendo la primera vez que tengo oportunidad de manejar un Raspberry Pi, tardé algunas semanas en adaptarme)
  • Para finales de Octubre, ya tenía el Raspberry Pi funcionando a la perfección, junto a otros servidores adicionales prestados. Luego, por esos días con Donato y dx (dos miembros del proyecto) fuimos a ayudar a acomodar otro nodo en Pampahasi, desde donde yo podía hacer un enlace.
  • Empezando Noviembre adquiero una antena Ubiquiti más para reforzar los enlaces de la Red Libre: luego de solucionar problemas triviales (terminar de acomodar todos los servidores y cambiar un cable troncal que se había dañado), finalmente inauguro el Nodo.

Reconocimientos e información adicional

Las siguientes personas ayudaron mucho para que la Red Libre dé este paso importante:

• Rodrigo Garcia (@strysg), por haber escrito El Botadero y mantenerlo como un proyecto de software libre, y además por la ayuda para mantener los servidores del proyecto online y hacernos dar cuenta cuando algo lo estamos haciendo mal.
• Donato (aymAtha) y a Dx por ayudarme en momentos complicados como el traslado o montaje de antenas o servidores, y en ayudar a la aventura del nodo en Pampahasi, armado en plena noche.
• Sergio Guillen, por aportar con conocimiento técnico y ayuda física para ir concretando las metas de la Red Libre. Y por los ánimos que inspira para continuar con el Proyecto, cuando alguna vez sentimos que perdimos el horizonte.
• Armin Mesa, por haberme dado la confianza de continuar trabajando con las cosas del proyecto, y haberme abierto de buena gana las puertas del Hacklab.
• Philippe Rivière, una de las pocas personas que confió en el sueño loco de un grupo de «hackers», y decidió ayudar desinteresadamente a impulsarlo.

En realidad hacen falta listar a muchas más personas que han ayudado al proyecto, de una manera u otra (por ejemplo: a una persona en específico le debo el hecho que me haya acercado al Hacklab), pero la lista sería tan larga que no terminaría de escribirla hasta dentro de dos días.

Imágenes

Para que puedan ver más de cerca el ambiente:  

Actualmente estoy experimentando con 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.   Para no perder registros podemos aumentar el TTL de las asignaciones a 12 horas, pero en un evento de uso masivo muchos usuarios se quedaran sin conectarse (dnsmasq reservará por 12 horas una dirección IP aunque el primer usuario sólo la use dos minutos, y si no hay más direcciones disponibles no responderá y la conexión fallará). Se me ocurrió una idea bien cruda: se puede mantener un TTL más bajo (30 minutos) y obtener las combinaciones fecha-hora-IP-MAC desde logread.

Par esto, necesitamos que el tamaño de buffer del registro de sistema sea grande, al menos 64K (OpenWrt suele configurarlo por defecto a 16K). Esta opción esta en el menú Sistema de LuCI.

Obteniendo combinaciones Fecha-IP-MAC-Hostname

logread | grep dnsmasq | grep ACK | cut -d " " -f 1-6,10-12

Con este comando 1) obtenemos el registro syslog, 2) filtramos los registros no-dnsmasq, 3) obtenemos las direcciones DHCP medianamente bien negociadas, y eliminamos columnas de datos innecesarias. Al final obtendremos registros parecidos a éste:

Sun Dec  4 10:17:48 2016 172.24.0.163 c8:38:70:6d:xx:xx android-d2c1e0088xxxxxxx Sun Dec  4 10:20:49 2016 172.24.0.186 38:d4:0b:f9:xx:xx android-12d628c44xxxxxxx Sun Dec  4 10:39:13 2016 172.24.0.145 20:55:31:d0:xx:xx android-5e4e127c2xxxxxxx Sun Dec  4 10:44:18 2016 172.24.0.183 3c:bb:fd:b1:xx:xx android-6596fdce1xxxxxxx

Obteniendo combinaciones únicas IP-MAC-Hostname

logread | grep dnsm | grep ACK | cut -d " " -f 10- | sort -n | uniq -u

Con este comando 1) obtenemos el registro syslog, 2) filtramos los registros no-dnsmasq, 3) obtenemos las direcciones DHCP medianamente bien negociadas, 4) eliminamos columnas de datos innecesarias, 5) ordenamos los registros y 6) eliminamos los registros duplicados. Al final obtendremos registros parecidos a éste:

172.24.0.132 d4:a1:48:cf:xx:xx android-6c2612059xxxxxxx 172.24.0.136 ac:cf:85:d8:xx:xx android-3ed8050aaxxxxxxx 172.24.0.142 1c:cb:99:a4:xx:xx android-aef6895bbxxxxxxx

Tengo en mis manos un TL-WA5210G V1 (punto de acceso/repetidor/router Wi-Fi de largo alcance). Como ya pudieron leer en algún anterior post (…), casi todos los sistemas que manejo funcionan con firmware alternativo.

Revisando el aparato

Acá voy a contar lo que logré investigar. He logrado instalar al aparato OpenWRT Chaos Calmer (2015) luego de meses y meses de pelea, incluso teniendo que compilarme mi propio firmware. Si lo quieres lo puedes descargar. Lo explico mejor luego. (Ya existe firmware oficial)

Viendo cómo se puede mejorar la funcionalidad de este aparato, e investigando un poco, llegué a estas conclusiones:

• Este aparato no usa Linux en absoluto: el firmware se basa en VxWorks. VxWorks es detestable.
• Tenemos 16 MB de RAM, y 4 MB de ROM. El firmware sólo usa 2 MB de ROM.
• VxWorks es bueno para tareas simples. Pero es bastante restrictivo, y es algo inestable. No esperes más de lo que ofrece.
• No hay soporte de parte de DD-WRT para este aparato.
• No hay soporte directo de parte de OpenWRT (a menos que quieras «ensuciarte las manos» compilando una versión vieja)
• En este caso, no siempre es buena idea usar firmware basado en Linux. (16 MB es poco, y OpenWrt accede a sólo 13 MB; si quieres comodidad al administrar, o sea instalar LuCI, funcionará muy lento)
• Si insistes en usar OpenWRT, tienes que cambiar el bootloader de VxWorks (un simple descompresor) por RedBoot.
• El TP-LINK TL-WA5210G V1 y el Ubiquiti Nanostation 2 son, casi, clones hardware.

Aquí la cosa se pone interesante: luego descubro que existe un port de AirOS para mi aparato TP-LINK…

Acerca del port de AirOS

• Este firmware NO es crackeado ni ilegal.
  • El SDK de AirOS era software libre, pero por repetidas «violaciones a su propiedad intelectual», Ubiquiti cerró el firmware. (y con razón)
  • Este firmware se basa en ese SDK. Por las anteriores razones, no hay actualizaciones (la última versión salió en enero de 2013).
• Este firmware NO es oficial.
• Este firmware sólo soporta la versión V1 del hardware TP-LINK
• La versión AirOS es 4.x (¿o 3.x?)
• Este firmware es gratuito (pero no es software libre).
• El programa instalador/flasheador es privativo, y exige pagar por cada dispositivo a flashear.
• Este programa es esencial, ya que reemplaza casi todo el contenido de la ROM, incluyendo el «bootloader». No se salva ninguna partición: incluso se modifica la MAC.
• Si instalas AirOS, NO es posible volver al firmware VxWorks de TP-LINK.
• Existen versiones pirata del software flasheador, pero que flashean los dispositivos con la misma MAC (peligroso)

Instalando el firmware AirOS

Tomando en cuenta lo que leíste arriba, vamos a empezar a trabajar. La versión del TP-LINK Reprogrammer «5210G_beta2», aunque funciona bien para flashear, tiene un bug de validación de licencia. Gracias a este bug es posible instalar AirOS sin tener que comprar una «licencia» a los autores de este hack. Más detalles no me acuerdo: puedes empezar de acá. Busca la versión que indiqué arriba y usa esa. Ojo con la «mac legal» que incluya: no me acuerdo cuál usé, pero una sí te deja conservar la identidad de la MAC de tu aparato. Suerte.

Instalando el firmware OpenWRT

Necesitas descargar el firmware:

https://downloads.openwrt.org/chaos_calmer/15.05/ath25/generic/openwrt-15.05-ath25-ubnt2-squashfs.bin

Sólo necesitas actualizar desde la interfaz de AirOS y ya tienes OpenWRT en el aparato.