El Taller de Luis

Autor: Luis Mita

  • Revivamos las comunidades de la Carrera de Informática

    Revivamos las comunidades de la Carrera de Informática

    En la Carrera de Informática (UMSA), los grupos de estudio y comunidades son independientes.

    Esto tiene varias interpretaciones, si, pero me refiero a la libertad creativa: como estos nacen siempre desde los estudiantes, podemos avanzar los temas que son de nuestro interés y profundizar, incluso si no se cuenta con el apoyo desde la Carrera. Esto es importante, ya que en casos como competencias de programación y seguridad, esa libertad fue importante para poder llevarnos premios importantes 🙂

    También es claro que esa libertad de organización y armado hace que cerrar un grupo sea tan fácil como abrirlo, y que varios al no tener un plan adecuado, terminan inactivos o muriendo.

    Si queremos retomar nuestro puesto vanguardista como una Carrera líder, necesitamos más grupos de estudio, con gente nueva y que realmente quiera enseñar.

    Ciclo de Vida

    Crear un grupo de estudio es sencillo. Requiere, antes que nada, reunirse con algunas personas que piensen como tú, y que estén interesados en aprender y/o enseñar algún tema que tengan en común.

    Luego de eso es oficializar la creación (lo detallo en otro post futuro), ¡y ya puedes iniciar con tus actividades!

    Un SoC para routers, y su RAM. En mi caso estuve trabajando con ellos en 2025, y me tocó hacerlo solo.
    ¿Será tarde para un grupo de estudio de embebidos?

    Todo es voluntario

    Nótese que, al no ser parte del cogobierno ni de los centros de estudiantes, los grupos de estudio no tienen beneficios ni tampoco algún derecho especial (aparte de ser estudiantes legales y matriculados), y en rasgos generales, eso ayuda a mantener los grupos como lugares donde puedes encontrar gente académica. Claramente eso no es una garantía xD pero creo que es algo bueno, aunque eso dificulte cosas como conseguir ambientes o realizar proyectos de peso.

    Bueno, ahí está: se necesitan voluntarios. Invertirías tu tiempo en un producto para beneficio de otros. Quizás si haces algo popular, consigas puntos para el currículum, pero no más que eso.

    Pósters random. Desconozco su origen, pero me gusta el concepto de recaudar en una parrillada para los bomberos voluntarios.
    Como se ve, los grupos de estudio deben aportar de su dinero para mandar a imprimir sus afiches, por eso varios son fotocopias nomás.

    Entonces, ¿por qué invertir ese esfuerzo?

    Depende de la persona. En mi caso, siempre vi que, cosas que hacemos en la Carrera, las podemos hacer mejor. Y qué mejor manera de agradecer lo que recibimos de la Universidad aportando más conocimiento.

    Esto fue una constante permanente en mi vida:

    • Con el r00thouse buscamos crear una red inálambrica comunitaria a lo largo de La Paz.
    • Con LaOtraRed buscamos, como bolivianos, apropiarnos de los servicios que consumimos. ¿Por qué dejar nuestros datos en manos de las Big Tech, si podemos armar esos servicios nosotros mismos?
    • Cuando me uní al Núcleo GNU/Linux, vi la importancia de que en la Carrera vean que este S.O. es una alternativa seria. Sobretodo ahora, con un Windows 11 lento, inestable, que te espía y te fuerza a consumir productos con IA.
    • Mi proyecto de tesis trata de rescatar routers y superpotenciarlos con software libre y Linux. ¿Por qué comprar aparatos carísimos y con licencia para el Wi-Fi, si con software libre podemos hacerlo mejor y por menos precio?

    Compartir para mí es natural, de ahí es que, a pesar de no tener ya mucho tiempo, trato de estar presente en varias actividades.

    Elige tu motivo por el que quieres ser parte.

    Tema de tu grupo

    ¿Qué harás? ¿Con qué tecnología trabajarías?

    Esto es un tema algo complicado, no por lo técnico sino por lo social.

    Digamos que deseas trabajar en diseño frontend. Hay ya uno o dos grupos que trabajan con frontend. ¿Cómo afrontas el problema?

    La recomendación suele ser revisar los demás grupos y contactarse con ellos. Colaborar suele funcionar: los Code Cats tienen una alianza con Ctrl+Dev para sus clases. Tu red de contactos aumenta, tienes acceso a más expertos y la gente está contenta.

    Si no funciona o no lo ves adecuado, siempre puedes crear un grupo nuevo y hacer las cosas de la manera que tú creas correcta. Ya ha pasado con grupos que trabajaron con Arduino, tecnologías móviles o desarrollo.

    Actividades

    ¿Qué actividades se pueden hacer?

    Igual, depende del grupo. No todos los grupos de estudio dan clases: algunos se concentran en eventos, como charlas o hackatones. Mi preferencia personal son los proyectos: es más fácil coordinar con pocas personas y meternos de lleno a un tema.

    Mi recomendación: no importa qué, pero hagan cosas. Muchos grupos apuntaron a hacer cosas grandes, y pocos lograron terminarlas. A muchos les faltó el tiempo, otros no recibieron apoyo y se congelaron.

    Se necesitan más

    Si hay alguien interesad@ en el tema, puede contactarse conmigo, ya sea para poder ayudarle en algo o derivarle a la persona que puede saber más.

    En un futuro, en otro post espero detallar más información 🙂

  • 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.

  • Mini Taller de Sockets en Python: Uso de Sockets para Internet

    El Taller a resolver es éste:

    Se pueden notar que nos permiten solo usar el módulo de Sockets, no podemos usar cosas como Requests 🙁

    Introducción

    Para esto necesitamos usar Python. Hay varias formas de prepararlo:

    • Usar Colab, que tiene un intérprete Python online que podremos usar sin instalar nada. (OJO: leer la nota de Colab al final)
    • Instalar Python para Windows, y como IDEs podemos usar VS Code, o PyCharm.
    • Usar una imagen de Debian en Virtualbox. Una instalación de escritorio normal ya viene con Python preinstalado y listo para usar.

    1. El programa debe recibir dominios de Internet y devolver la IP de cada uno.

    En otras palabras, debemos resolver los dominios a su IP.

    Tomen en cuenta que se pidió como argumento una lista de dominios, que pueden ser uno, dos, muchos o ninguno. Tendremos que iterar.

    Cuando ejecutamos un programa, podemos pasarle argumentos (como cat programa.py). En Python leeremos los argumentos que el usuarios nos dé, con el módulo sys.

    Código:

    import socket # Importamos el módulo socket
import sys

# Ejecuta el programa como:
# python3 ej1_resolvedor.py www.google.com www.facebook.com www.youtube.com

client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # Creamos un objeto socket

for x in sys.argv: # Recorremos tooodos los argumentos pasados al programa
    if x != sys.argv[0]: # Ignoramos el primer argumento (que es el nombre del programa en sí)
        hostname = x
        try:
            ip_address = socket.gethostbyname(hostname) # Solicitamos al PC resolver el hostname a su dirección IP
            print(f"La IP de {hostname} es {ip_address}")
        except socket.gaierror as e:
            print(f"Error: {e}") # Si no se puede resolver el hostname, se imprime el error

client_socket.close() # Cerramos el socket

    Esto usa una funcionalidad integrada del módulo de sockets, donde la parte de la resolución del dominio se lo delega al sistema.

    También se puede armar una versión donde tú te comuniques directamente al DNS, y en «idioma DNS» tú le pidas que te resuelva el dominio. Hacer eso es una locura, pero si alguien lo quiere probar puede verlo.

    2. Programa que dé la hora

    Esto se puede hacer con Python, aperturando un puerto TCP/9876 y pueden usar código de ejemplos en Internet, de guías o de otros paralelos.

    Cada vez que cualquiera se conecte, este debe devolver la hora y luego cerrar la conexión.

    Para el programa cliente, se puede usar cualquiera que abra una conexión súper simple. Telnet es un protocolo que abre conexiones simples, y podremos aprovecharlo:

    En Linux podemos conectarnos así: telnet localhost 9876.
    En Windows o Linux podemos conectarnos con el programa Putty de esta manera:

    3. Cliente HTML que reciba una dirección web y la abra.

    Este programa usa un Socket TCP cliente.

    El programa, a grandes rasgos, debe:
    1) Resolver el dominio, tal como está en 1.
    2) Abrir una conexión TCP cliente a la IP, puerto 80.
    3) Enviarle una Petición
    4) Recibir el contenido y mostrarlo con print().

    La Petición la debemos hardcodear y sería algo parecido a esto:

    GET / HTTP/1.1
HOST: google.com
Accept: */*

    La primera línea pide el archivo
    La segunda pide el dominio
    La tercera le dice al server que aceptaremos todo lo que nos dé.

    4. Servidor web de archivos

    Lo que nos piden:

    • Que el servidor corra continuamente
    • Que se revise si algún archivo pedido exista, si es el caso, abrirlo
    import socket # Importamos el módulo socket

# Declaramos la funcion Pedido
def pedido(conn):
    # Llega un pedido
    request = conn.recv(1024).decode() # Recibimos el pedido y lo ponemos en un string

    if 'GET ' in request: # Si el pedido es un GET
        file_name = request.split()[1][1:] # Obtenemos el nombre del archivo pedido
        print("Archivo pedido: "+file_name)
        try:
            with open(file_name, 'r') as f: # Abrimos el archivo pedido
                response_body = f.read()
                response = f"HTTP/1.1 200 OK\r\n\r\n{response_body}" # Respondemos
        except FileNotFoundError: # Si el archivo no existe, devolvemos un error
            response = "HTTP/1.1 404 Not Found\r\n\r\nFile Not Found"
    else: # Si nos piden algo que no es GET
        response = 'HTTP/1.1 405 Method Not Allowed\r\n\r\nMethod Not Allowed'

    conn.sendall(response.encode()) # Enviamos 
    conn.close()


# -------------------------
# Inicio del programa
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # Creamos un objeto socket
server_socket.bind(('0.0.0.0', 8888)) # Asociamos el socket a un host y puerto
server_socket.listen(5) # Ponemos el socket en modo escucha
print('Servidor Funcionando.')

while True: # Bucle infinito, termina una peticion y esperamos otra
    client_socket, addr = server_socket.accept() # Si hay una conexion de entrada, la aceptamos y la mandamos a la funcion Pedido
    pedido(client_socket)

    Este código da una idea de la funcionalidad más básica de un web server.

    Faltan varias cosas:

    • Cambiar número de puerto de escucha
    • No implementa Content-Type, lo cual complica el usarlo con navegadores web
    • No implementa Content-Length
    • No genera un listado de páginas dentro de la carpeta, o sea para probarlo tendremos que escribir todo el URL a mano.
    • No se valida lo que pide el cliente. Alguien podria intentar hackear el webserver con algo como http://localhost:8888/../../../../../etc/passwd

    Sobre el uso de Colab

    En la evaluación, necesitamos ejecutar el programa Python como un archivo «.py» y pasarle argumentos.
    En Colab no se puede pasar argumentos, pero una forma de hacerlo sin tocar el código es:

    import socket
import sys
sys.argv[1] = "google.com"
sys.argv[2] = "facebook.com"

(...)

    Inicias desde el 1, y en el 2 o 3 puedes ir poniendo los dominios que quieras.
    Esto es técnicamente «usar argumentos», pero esto no está probado si será válido en la defensa.

  • Cómo preparar un servidor DNS en Debian

    Tenemos una Guía en la materia y los ejercicios son estos:

    Requerimientos para empezar

    Instalar bind9, el server DNS. En la máquina virtual Debian, luego de entrar como root usando su, puedes instalarlo con estos comandos:

    apt update; apt install bind9

    El servidor DNS se instalará e iniciará solo 🙂

    Inciso 1

    Probar el bind9 como server caché y registrar el tiempo de consulta.

    Editar el archivo named.conf.options. Descomentar y editar la sección de forwarders, poniendo una IP. Como ejemplo: 1.1.1.1

    Recargar el servicio systemctl restart named

    Probar con consultas dig:

    dig @8.8.8.8 facebook.com
dig @127.0.0.1 facebook.com
dig @127.0.0.1 facebook.com

    Una captura de la salida del comando dig:

    (1) les muestra el TTL (time to live), o sea por cuántos segundos la respuesta será válida. Útil para la caché.
    (2) les muestra la respuesta de la consulta DNS. Acá preguntamos por la IP de facebook.com, y ya nos dieron la respuesta.
    (3) les muestra cuánto tiempo duró la consulta. Si instalaron la caché, la cifra debe ser muy pequeña, entre 0 o 2 ms.

    Inciso 2

    Configuraremos la zona primaria en bind9.

    Editamos /etc/bind/named.conf.local y agregamos esto:

    zone "ejemplo.com" {
type master;
file "/etc/bind/db.ejemplo.com";
};

    Ahora agarramos una plantilla existente de la zona y la copiamos
    cp /etc/bind/db.local /etc/bind/db.ejemplo.com

    Editamos la zona
    nano /etc/bind/db.ejemplo.com

    Aparte de editar lo existente, podemos agregar algunos subdominios al final. Por ejemplo, puse

    informatica    IN    A    12.34.56.78

    siendo 12.34.56.78 una IP inventada.

    Ojo que las IPs se componen de 4 números, cada uno de un valor entre 0-255.
    Una IP como 456.789.999.999 no es válida.

    Para aplicar los cambios, reiniciamos el servicio:
    systemctl restart named

    Antes de reiniciar, también podemos verificar la sintaxis con el comando
    named-checkconf
    Si todo está bien, no te dirá nada.
    Si algo está mal, te lanzará un mensaje de error.

    Inciso 3

    Parte 1: Probar lo que hicimos

    Usar dig @127.0.0.1 dominio.com

    Luego verificamos que la respuesta es correcta.

    Podemos hacer la prueba también con nslookup:

    Parte 2: crearemos una zona inversa

    Una zona normal, como vimos, administra un dominio entero, como «ejemplo.com» y podemos apuntar hacia IPs.

    Una zona inversa administra un bloque de IPs tuyos (ej, si te armas una red con un router, puedes administrar todas las IPs en el rango 192.168.1.1-192.168.1.254). Ahora, a cada IP podemos apuntarle un dominio.

    O sea, con una zona inversa podemos bautizar IPs y les pondremos los nombres que queramos!

    Editamos /etc/bind/named.conf.local y agregamos

    zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168.1";
};

    Usamos el bloque de IPs pero al revés (por eso está como 1.168.192) y le ponemos «in-addr.arpa».
    Esto es una convención. O sea, los creadores de Internet le pusieron «in-addr.arpa» por que sí.

    Ahora agarramos una plantilla existente de la zona y la copiamos
    cp /etc/bind/db.local /etc/bind/db.ejemplo.com

    El tipo de registro ya no es A, ahora es PTR.

    Reiniciamos el servicio con systemctl restart .named

    Ahora podemos hacer la prueba con dig:

    Nótese que las consultas en dig las hacemos ahora con-x.

    Inciso 4

    Obtendremos el DNS actual de /etc/resolv.conf, que por defecto es el del router (y este suele apuntar al proveedor)

    AXS tiene el DNS 200.105.128.40
    Entel 200.87.100.10
    Tigo 190.104.12.242


    En mi máquina el DNS es 10.64.64.54.

    Desde su conexión a internet deben probar los servicios de su ISP, de google y de Cloudflare, y comentar cuál es más rápido (revisando la salida del comando dig)

  • Transmission Rate Podcast 10 – Dj Set Primavera 2024

    Transmission Rate Podcast 10 – Dj Set Primavera 2024

    Tenemos nuevo episodio del Podcast para este cambio de estación 😀

    Para esta edición:

    • Este set se grabó en directo.
    • «Aire Santo» es el primer track. Parte del nuevo álbum de Cocaibica, este pone un inicio fresco al set.
    • Para esta ocasión hay tres IDs. Ninguno salió en otros sets míos en Internet, y el primero (minuto 10:41) es uno muy reciente. Espero usarlo en otros sets 🙂
    • Como es costumbre, el tracklist está en los comentarios.

    Un saludo, ¡y nos vemos en un próximo episodio!

  • 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.

  • El puerto escondido donde puedes hacer lo que quieras con un router, incluso destruirlo

    Los sistemas Linux suelen estar presentes en muchos aparatos, y aunque hablamos de routers, mucho de esto se aplica a cámaras de seguridad, alarmas wifi, incluso a microcontroladores.

    Si uno quiere programar o armar uno, ¿como nos comunicamos? ¿Cómo le instalas el firmware? Si algo falla, ¿cómo rescatas el aparato?

    Por una entrada serial, o un puerto UART, etc. (ambas cosas son prácticamente lo mismo)

    Si nuestro Linux tiene un problema, nos podemos conectar a una terminal para arreglarlo si queremos. De la misma manera los routers y demás aparatos tienen un puerto serial, donde podemos acceder a una terminal.

    Imagen ilustrativa.

    Esta funciona gracias al bootloader, que es código que corre apenas inicia el router. Ese código enciende la placa y hace alguna verificación del estado de lo más esencial, que sería la ROM y la RAM. Luego, si hay un sistema Linux, lo inicia.

    Cuando Linux no puede iniciar

    A veces el sistema operativo dentro del router se rompe. Quizás una actualización falló, y ahora el equipo no puede iniciar.

    El bootloader más común, U-Boot, puede ayudarnos. Con una combinación de teclas (Escape, el número 4, etc.) podemos detener el boot y nos da acceso a una línea de comandos. Desde ahí se puede:

    • Cargar un sistema operativo a la RAM desde la PC
    • Arrancar el sistema desde ahí mismo
    • Copiar el sistema a la memoria Flash
    • Analizar partes de la memoria (RAM y ROM)

    En el caso de la primera fotografía, bloqueé sin querer OpenWrt por una mala configuración (perdí una clave SSH privada) y no pude ingresar más, ya que había «hardenizado» el router para evitar intrusiones y los métodos de reseteo no funcionaban. Al final gracias a UART desarmé el aparato, y desde el modo serial pude resetear el router por completo.

    Mucho hardware que se cree dañado puede arreglarse así 🙂