Contexto
En la ciudad de Bahía Blanca, el grupo Sudoeste Mesh (SOMesh) modificó el preset LoRa de LongFast a MediumFast, lo que mejoró notablemente la comunicación entre todos los nodos de la red. Este instructivo se basa en esa experiencia y utiliza la configuración ANZ (para Argentina) con el preset MEDIUM_FAST como punto de partida.
Escenario inicial: crear una malla completamente aislada
Partimos del siguiente caso práctico:
"Quiero armar una flota de equipos que se comuniquen exclusivamente entre ellos, sin participar ni ver el tráfico del canal público MediumFast (o LongFast). Mi canal 0 debe ser privado."
¿Qué ocurre al configurar un nodo con el preset ANZ - MEDIUM_FAST? Cuando elegimos este preset, Meshtastic asigna automáticamente el slot de frecuencia N° 45, lo que equivale a transmitir en 926,125 MHz. Si en cambio usáramos el preset ANZ - LONG_FAST, el slot sería el N° 20 (918,875 MHz). Estos números de slot son valores predefinidos por el software para cada preset, no son aleatorios.
Un detalle clave: los canales de Meshtastic (como MediumFast o Privado) no están vinculados físicamente al slot de frecuencia. El software, al aplicar el preset, simplemente dice: "Ok, el preset es MEDIUMFAST, entonces para ANZ uso el slot 45, y configuro el canal 0 como 'MediumFast' abierto".
El truco para aislar la red
Si lo primero que hacemos al configurar un nodo es eliminar el canal 0 'MediumFast' por defecto y crear en su lugar un canal propio con una PSK (clave precompartida) generada por nosotros, Meshtastic puede reasignar automáticamente el slot de frecuencia. En mis pruebas, al hacer esto, el slot pasó del 45 al 30.
¿Qué implica esto? Que todos los nodos que compartan ese nuevo canal 0 privado (con la misma PSK) trabajarán en el slot 30, es decir, en 922,375 MHz. Como la malla pública opera en el slot 45 (926,125 MHz), ambas redes no se ven entre sí. Los nodos privados formarán una malla totalmente independiente, y ningún equipo de la malla pública podrá escuchar ni retransmitir sus mensajes.
Topología de una malla privada aislada
Supongamos que tenemos cuatro nodos, todos configurados con el preset ANZ - MediumFast, pero operando en el slot 30 (el que Meshtastic asignó automáticamente al eliminar el canal público):
| Nodo | Canal 0 | Rol | Observación |
|---|---|---|---|
| Nodo 1 | 'Privado' (con PSK propia) | CLIENT_MUTE | Equipo de usuario |
| Nodo 2 | 'Privado' (con PSK propia) | CLIENT_BASE | Nodo fijo en altura |
| Nodo 3 | 'Privado' (con PSK propia) | CLIENT_MUTE | Equipo de usuario |
| Nodo 4 | 'Privado' (con PSK propia) | CLIENT_BASE | Nodo fijo en altura |
Esta configuración crea una red completamente cerrada e independiente. El slot 30 (922,375 MHz) asegura que ni siquiera compartan frecuencia con la malla pública (slot 45 / 926,125 MHz). Es un aislamiento total: no se ven, no se escuchan, no retransmiten.
Escenario optimizado: malla privada que colabora con la red pública
Queremos mantener nuestra malla privada cifrada, pero colaborar activamente con el enrutamiento de la malla pública (sin participar en sus conversaciones). Para lograrlo, debemos hacer algunos ajustes:
Pasos para integrar sin perder privacidad:
- Forzar todos los nodos al slot 45 (el de la malla pública). Para ello, debemos mantener el canal 0 como 'MediumFast' en los nodos base.
- En los nodos base (CLIENT_BASE): eliminar el canal privado y dejar únicamente el canal 0 'MediumFast' con su clave pública por defecto (AQ==).
- En los nodos de usuario (CLIENT_MUTE o CLIENT): mantener el canal 0 privado con la PSK propia, pero ahora operando en el slot 45.
Topología resultante:
| Nodo | Canal 0 | Canal 1 | Rol | Slot |
|---|---|---|---|---|
| Nodo 1 | 'Privado' (PSK propia) | — | CLIENT_MUTE | 45 |
| Nodo 2 | 'MediumFast' (AQ==) | — | CLIENT_BASE | 45 |
| Nodo 3 | 'Privado' (PSK propia) | — | CLIENT_MUTE | 45 |
| Nodo 4 | 'MediumFast' (AQ==) | — | CLIENT_BASE | 45 |
¿Cómo funciona esto?
- Los nodos CLIENT_MUTE (Nodo 1 y 3) transmiten su tráfico privado cifrado en el slot 45.
- Los nodos CLIENT_BASE (Nodo 2 y 4), al tener el canal 0 público, participan activamente en el enrutamiento y retransmisión de todos los paquetes que captan, tanto públicos como privados.
- Cuando un nodo ajeno a nuestra red captura un paquete de nuestra malla privada, lo retransmite aunque no pueda descifrarlo, porque el protocolo Meshtastic está diseñado para reenviar todo paquete bien formado, independientemente de que esté cifrado.
Conclusión parcial: todos ganan. Nuestra malla privada se extiende geográficamente gracias a la colaboración de los nodos públicos, y al mismo tiempo colaboramos con el enrutamiento de la red abierta.
Extendiendo la funcionalidad: nodo híbrido
Ahora supongamos que queremos agregar un quinto nodo que cumpla una doble función:
- Participar del canal público MediumFast (canal 0).
- Tener acceso a nuestra malla privada (canal 1).
Configuración correcta para el nodo híbrido
| Parámetro | Valor |
|---|---|
| Preset | ANZ - MediumFast |
| Slot | 45 (forzado si es necesario) |
| Canal 0 | 'MediumFast' con clave AQ== (la pública por defecto) |
| Canal 1 | 'Privado' con la misma PSK que el resto de los nodos de la malla cerrada |
Advertencia importante
No se debe cambiar el orden de los canales.
Si movemos el canal MediumFast a otra posición (por ejemplo, convertirlo en canal 1 y el privado en canal 0), Meshtastic reasignará el slot automáticamente y perderemos la frecuencia 45. Además, podrían dejar de funcionar correctamente funcionalidades críticas como:
- Telemetría (datos de batería, señal, etc.)
- Posicionamiento GPS
- Acuse de recibo (ACK) de los mensajes
En el diagrama adjunto, el Nodo D representa esta configuración correcta, mientras que el Nodo A muestra el ejemplo incorrecto (con los canales invertidos o mal ordenados).
