Entonces de momento el plan es tener 8 libremesh y 8 openwrt? Y cada par estará físicamente cerca, conectados por cables?
@bruno es la propuesta que salió en aquel momento, por otro lado, puede requerir de más testeo (configuraciones específicas, bridge, evitar loops, etc.).
Por otro lado, en una reunión exprés con marek, comentó que también podria ser necesario la necesidad de apagar y encender remotamente los routers que podrían quedarse potencialmente en un kernel panic (por ejemplo para un escenario de pruebas de reproducir un bug report de batman advance). Alguna vez se habló de usar un dispositivo IoT LoRa para el control de energía on/off, otra alternativa es via switch PoE conectar/desconectar.
Lo que estoy mirando ahora es un testbed rápido (asumiendo que falible y vulnerable) pero que nos dé posibilidad de experimentar cierta coordinación remoto-presencial con lo que pase en battlemesh v16 la semana que viene
En Coolab alguna vegada hem probat d’utilitzar aquests relays programats amb chips ESP-01: Caramelo com ESP01 - Wiki Coolab. Però un sistema IoT ens pot donar solucions més senceres.
When we will have the two parallel networks LibreMesh (management) and OpenWrt (testbed), if we want to have the remote reset option, I would use the GPIO from the management router to “press” the WPS/Reset button on the testbed router.
https://openwrt.org/toh/tp-link/tl-wdr4300_v1#gpio
But this is still far in the future.
Perdó se m’ha sortit l’anglés.
Hem de decidir què fer amb la contrasenya de root.
Una opció és desabilitar el login amb contrasenya per SSH.
Aquí ho fan des del fitxer de lime-community:
També, copian les claus SSH d’una forma més elegant de la que vig posar jo, crec que l’hauriem de copiar.
Els fitxers amb les claus i el fix dels permisos són aquí:
He agafat tot aquest tros de conversa i ho he mogut a part perquè estem parlant sobre gestió del testbed i així queda ordenat, no? 
Avui he parlat una estona amb @Carlos.lopez sobre si seria possible properament d’afegir els nodes del testbed per fer-los anar a la battlemesh, al cap i a la fi intentarem explicar-lo i que el facin servir (si voleu participar en la presentació, etc. em dieu, serà tot una mica caòtic i maraton, no és ideal blabla, però és bona oportunitat d’anar tancant algunes coses, o de tenir-ho ni que sigui en una primera versió a partir de la qual podem iniciar un nou cicle).
Pueees, @Carlos.lopez m’ha dit que els 6 emplaçaments proposats (que tirem-los endavant i ja parlem més endavant com segueix més endavant xD), es poden cablejar molt fàcilment (
) a través d’una xarxa dedicada. Això és possible perquè hi ha rosetes que es poden patchejar al rack de comunicacions. També hi ha switchos grans amb PoE per fer gestió d’encendre i apagar els dispositius.
Alternativament, potser també podríem jugar de posar algun aparell intermig que pugui encendre i apagar alimentació elèctrica via LoRaWAN (hola @Iker !).
@ilario no sé si n’hi ha prou amb un botó que apreta WPS/Reset button; funcionaria pel següent cas d’ús de reestablir sistema si es queda pajaritu o després d’un kernel panic d’un batman-advance? Ho dic perquè Marek, en algun moment penjarà una proposta d’experiment per arreglar-reproduïr un bug report de batman-advance i va comentar que en aquests casos són situacions que es poden donar.
Ja que una alternativa seria que enlloc de gastar un dispositiu del testbed per fer això (que crec que perd gràcia tenint en compte que la xarxa pot ser cablejada; almenys contra aquests 6 routers) seria, novament, dispositiu IoT LoRaWAN (hola @Iker xD) que fa d’actuador del GPIO de WPS/Reset button?
Gràcies per compartir-lo bruno, això és un watchdog de ping, provoca un reboot si no respon al ping; pot estar bé, però també algun mecanisme adicional via LoRaWAN, etc.?
Existeixen dispositius específics per a la gestió de relés.
Aquest, que n’hem instal·lat en diferents ubicacions i funciona bé, duu també entrades analògiques(2), digital(2) i sortides digitals(2) a banda de la gestió de contactes secs/sortida relé(2).
Preu de proveïdor són uns 75€.
Altre opció seria posar-hi un Arduino (que pot tenir pila TCP/IP i connexió WiFi com a backup/gestió) o una raspberryPi amb un HAT LoRaWAN (per més EdgeComputing o si és compatible amb el vostre firmware) amb una sortida de relé.
La 1a opció són uns 35€+relé(5€) però sobretot perque és més manipulable.
Llavors també podem anar a solucions d’IndustrialShields amb LoRaWAN si voleu alguna cosa entre mig de les 2 opcions: https://www.industrialshields.com/shop?search=&order=&view_mode=grid&attrib=80-463
Ara mateix tenim cobertura de veïns: podrem posar un gateway a la teulada per cobrir el barri? Com a mínim sino una d’interior per cobrir el Canòdrom (sobretot llegint que hi ha disponibilitat de cablejat?) i assegurar cobertura.
Hola Iker, brutal informació comparteixes! No tinc ni idea de si es podria posar res a la teulada de canòdrom, lo que em van dir fa temps és que era bastant difícil el seu accés.
Responent i aportant informació sobre converses anteriors amb @iker, @ilario, @bruno
1. Resum gestió testbed out of band
Fent una mica de resum pel que fa a gestió testbed out of band (de quan el router no respon de cap manera):
- Solució barata i simple: la de @bruno, és un watchdog que es connecta a una wifi de gestió del dispositiu testbed, que podria ser específica del dispositiu (fent un 1 a 1 per a un access point BSSID concret)
- Solució més cara però completa: la de @iker, aquesta ens dona accés a aquests dispositius per operacions diverses (podria incloure lo de GPIO de reset que comentava @ilario ), amb molts etc. (programació microncontrol·lador que calgui). Seria algo en la línia que apuntava @bruno amb l’afegit d’un mòdul/HAT/afegit LoRaWAN
2. Proposta d’accés per password / contrassenya per defecte pel network profile de canòdrom
@ilario he fet la prova que tenia pendent, de com jo ho he fet fa temps amb temba (que per cert, em vaig copiar el seu dia d’openwisp si no m’erro), un mètode que també he vist recomanat aquí (llegit molt ràpid). Li he donat volta perquè funcioni amb shell posix i salt/hash millor que md5. Concretament amb -6 Use the SHA256 / SHA512 based algorithms defined by Ulrich Drepper. See <https://www.akkadia.org/drepper/SHA-crypt.txt>. ( src man openssl passwd)
per defecte, router openwrt sense contrasenya escriu la següent línia /etc/shadow per l’accés root que resulta en un accés sense password
root:::0:99999:7:::
amb aquest script estic fent una template de /etc/shadow amb una contrassenya root arbitrària (via variable password)
salt=$(openssl rand -base64 12)
# put here the secure password
password=FIXME
hashed_passwd=$(openssl passwd -6 -salt "$salt" "$password")
# template based on the /etc/shadow of `LiMe 2024.1-rc1 2024.1 first release candidate ((no branch) rev. 2e50c6c 20240405_1632)`
cat <<END
root:${hashed_passwd}:1:0:99999:7:::
daemon:*:0:0:99999:7:::
ftp:*:0:0:99999:7:::
network:*:0:0:99999:7:::
nobody:*:0:0:99999:7:::
ntp:x:0:0:99999:7:::
dnsmasq:x:0:0:99999:7:::
logd:x:0:0:99999:7:::
ubus:x:0:0:99999:7:::
END
@ilario , et sembla si t’inventes tu mateix una contrassenya la puges al network profile i ja ens la fas arribar? (ens ajudarà com a fallback si passa quelcom amb dropbear/ssh/etc)
3. ssh keys en network profile
No m’ho he mirat gaire @ilario , però tira endavant com consideris!
4. Offtopic: taller LoRaWAN ?!
Anant a offtopic, per cert @Iker, Crec que de tota la gent que conec a guifi.net ningú a posat mai un dispositiu IoT LoRaWAN per control·lar el relé d’un node. Valdria la pena llavors fer una sessió o taller amb vosaltres del tema (cc @bruno), per a molts de nosaltres, seria la primera vegada que interaccionaríem amb la xarxa LoRaWAN.
Agafo la numeració de @exopedro
1 i 4:
si tenim dues routers per cada node (un de management amb LibreMesh i un de testbed amb OpenWrt trunk (jo li posaría l’últim codi de desenvolupament, una imatge snapshot-trunk: Index of /snapshots/targets/)), amb el GPIO del router de management podem gestionar el botó de reset i també un relay per treure la corrent a l’altre node. Si posem dues routers en cada node, no crec faci falta LoRA.
2:
si desactivem el login per SSH amb contrasenya, no fa falta tindre contrasenya, no? Bueno, fa falta si es pot accedir per interfície web també… Doncs ok, poso alguna contrasenya.
Crec que posaré un script en uci-config que sobstitueixi “root::” amb “root:l’hash_de_la_contrasenya:”.
3:
Ok, vaig provant si funciona.
Mentrestant, Pedro, tu pots anar flashejant els 8 routers amb OpenWrt snapshot?
Considero que aquests són secundaris (són útils només en l’escenari fantàstic on aconseguim posar dues routers en cada node), però no necessiten configuració doncs els podem anar fent, si tens temps.
Actualització sobre el network-profile pels routers de gestió:
Es pot fer login amb contrasenya.
Fins ara tenim la contrasenya jo i Pedro, però també hi ha les claus SSH meva, de Pedro i de Angel.
Els routers tenen una IP statica a dins de la xarxa de gestió a la xarxa 10.0.0.0/16 i les IP son 10.0.0.X on X és el número del device.
La posició GPS la vaig posar aleatoria, una mica diferent per cada router.
Els routers tenen una IP statica a la porta WAN, que és la que estarà cara a la xarxa de testbed. Aquestes IP són 192.168.1.X/24 on X és el número del device.