eternityforest/lazymeshPreuve de concept de réseau maillé IoT/Ham Radio avec routage global sur Internet
Système de routage maillé qui prend en charge l'utilisation d'un proxy OpenDHT comme backend, permettant aux nœuds de communiquer directement via Internet. Très tôt pré-alpha, preuve de concept, peut ne pas fonctionner réellement, etc.
Ceci est destiné à la fois aux cas d'usage hobby/HAM et aux travaux IoT plus typiques grand public/commerciaux, mais ne cherche spécifiquement pas à remplacer Internet, ni à couvrir de grandes zones à fort trafic avec des antennes omnidirectionnelles.
Il n'a pas de routage par saut suivant de type Meshtastic, d'où le nom LazyMesh. Si vous souhaitez l'utiliser pour des applications hors réseau dans une zone dense, vous aurez probablement besoin d'antennes directionnelles et d'identifiants de route coordonnés manuellement.
Pour l'instant, c'est la seule application réelle. Ouvrez l'esquisse Arduino d'exemple, modifiez-la avec votre nom d'utilisateur et une clé de canal secrète qui doit être un mot de passe fort.
Tapez votre message dans le moniteur série Arduino, et vous devriez pouvoir discuter avec tous les autres appareils.
Les messages devraient passer tant que les nœuds sont soit sur le même réseau, soit que les deux ont un accès Internet.
Visitez le Client Web pour discuter avec le nœud via MQTT depuis Internet. Définissez simplement un nom d'utilisateur, ajoutez un canal, et saisissez le mot de passe du canal. Le nom du canal peut être quelconque et n'affecte que l'étiquetage dans l'interface utilisateur.
Vous pouvez également essayer l'esquisse d'exemple de données Lire/Écrire. Celle-ci expose l'ID de données 195 comme lisible, et l'ID de données 196 comme lisible et inscriptible. Allez sur le site, saisissez les détails de votre canal, et utilisez la boîte de dialogue de demande de données pour demander l'ID 196 à tous les appareils.
Ensuite, cliquez sur "définir" et définissez-le sur autre chose, puis essayez de le lire à nouveau.
Le Client Web est actuellement codé en dur pour utiliser test.mosquitto.org, cela changera à l'avenir.
Les nœuds ont besoin d'un moyen de synchroniser l'heure pour communiquer. Actuellement, s'ils n'ont jamais reçu l'heure d'une source fiable, ils définissent leur heure à partir de n'importe quel paquet aléatoire qu'ils voient.
Cela pourrait être un risque de sécurité permettant des attaques par rejeu, donc les appareils qui ont besoin de sécurité devraient avoir une source de temps fiable.
Une fois l'heure initialement définie, le code ajustera son temps système jusqu'à 1 seconde par jour pour rester synchronisé avec les autres nœuds, donc une dérive hors synchronisation ne devrait pas être un problème majeur.
Dans Lazymesh, tout est un canal, il n'y a pas de messages directs. Si vous en voulez, créez simplement un canal privé dédié.
Les canaux sont définis par un mot de passe, connaître le mot de passe permet un accès en lecture et en écriture.
Il y a 256 numéros de route. Chaque paquet en a un, et les répéteurs ne répètent que s'ils ont activé un numéro de route correspondant. Par défaut, tout est envoyé avec le numéro de route 0, qui est activé par défaut.
Cela n'affecte que les répéteurs, les nœuds écouteront n'importe quel numéro de route maillée s'il leur est directement destiné.
Les charges utiles des paquets sont des tableaux MessagePack. Ils alternent des identifiants de données entiers et des éléments de données. 192-256 sont réservés aux messages spécifiques à l'application.
L'ID 32 est destiné aux messages texte, qui peuvent être précédés d'un nom d'utilisateur et d'un deux-points.
L'ID 2 est utilisé pour un identifiant unique, qui doit être un entier. De nombreuses applications pourraient ne pas en avoir besoin du tout.
Ajoutez un octet de longueur de métadonnées et N octets de métadonnées.
Pour créer l'IV, prenez 12 octets aléatoires pour l'IV. Ensuite, chiffrez le tout. Préfixez l'IV et ajoutez 4 octets de tag d'authentification.
Ensuite, prenez les 8 premiers octets du hachage de l'ID de routage et convertissez-les en hexadécimal.
Le sujet MQTT sera lazymesh_route_HEX
Notez que nous utilisons un sujet de premier niveau. Ceci afin que vous ne puissiez pas utiliser de caractères génériques pour vous abonner à tous les canaux lazymesh à la fois sur les courtiers publics, ce qui permettrait de faire un DoS sur tout le monde assez facilement.
Juste les paquets bruts diffusés sur 224.0.0.251:2221
Rien de tout cela n'est finalisé !!!
Tous les nombres sont en little-endian.
1 octet d'en-tête :
2 bits type de paquet (1 ou 2, selon si on veut un ACK)
3 bits TTL sauts restants
1 bit autoriser le transport lent (LoRa, etc.)
1 bit autoriser le routage global
1 bit déjà routé globalement
1 octet d'en-tête 2 :
1 bit première tentative d'envoi :
Chaque fois que nous créons ou recevons un paquet, définissez ce bit. Après avoir essayé de l'envoyer,
effacez-le. Ainsi, tant que nous supposons que la perte de paquets est relativement faible, nous pouvons compter les répéteurs dans la zone
sans surcharge supplémentaire.
1 bit répéteur :
Marque que ce paquet doit être inclus lors du comptage des répéteurs.
Définissez-le si vous répéteriez le paquet ou un similaire, même si vous en êtes l'origine.
1 bit d'intérêt :
Si défini, le nœud qui l'a envoyé est directement intéressé par le canal,
pas seulement un répéteur. Si le premier envoi est également défini, il est traité comme un
ACK implicite.
1 bit localisation activée
Si ce bit est défini, les répéteurs peuvent ajouter des métadonnées de localisation aux paquets transmis vers Internet. Ces métadonnées doivent être chiffrées avec l'ID de routage comme clé,
ce qui signifie que les personnes à proximité pourraient vous suivre pendant 1 heure après que vous soyez hors de portée.
Pas implémenté nulle part pour le moment.
5 bits réservés à 0
1 octet numéro de route maillée
1 octet d'atténuation de chemin accumulée :
5 bits total
3 bits dernier saut
Chaque saut est un point de perte de chemin,
plus le coût supplémentaire heuristique que le transport applique.
1 point de perte supplémentaire devrait être à peu près la même "mauvaise qualité" que
10 dBm de perte supplémentaire sur Wi-Fi.
16 octets d'ID de routage :
Change toutes les heures, dérivé de la PSK du canal par un hachage.
La PSK est simplement le SHA256 de 16 octets du mot de passe.
L'ID de routage change toutes les heures et est le SHA256 de :
La lettre 'cr'
Le nombre d'heures depuis 1970 sous forme d'entier non signé 32 bits
la PSK
8 octets d'entropie aléatoire :
Utilisé dans le cadre de l'IV pour le chiffrement
4 octets d'horodatage :
Fait également partie de l'IV, empêche également les attaques par rejeu
N octets de texte chiffré :
Chiffré AES-GCM.
La clé de chiffrement change toutes les heures, et est le SHA256 de :
La lettre 'c'
Le nombre d'heures depuis 1970 sous forme d'entier non signé 32 bits
la PSK
6 octets de tag d'authentification :
Les 6 derniers octets sont le tag GCM.
Certaines implémentations peuvent choisir d'ignorer complètement cela.
Les ACK sont purement par saut, sauf si une couche de protocole supérieure veut des ACK de bout en bout.
Les paquets ACK ne sont ni répétés ni routés, ni authentifiés. Chaque étape de répétition maillée a sa propre accusé de réception, du point de vue de l'expéditeur d'origine, c'est "tire et oublie".
Comme Meshtastic et la plupart des autres, le protocole est "semi-fiable", il y a, comme tous les réseaux, des cas limites entraînant des échecs.
La fiabilité réelle doit être assurée à un niveau supérieur.
Pour chaque paquet, chaque auditeur intéressé de ce canal spécifique envoie un accusé de réception de canal exactement une fois, sauf s'il détecte que plus de 8 ACK ont déjà été envoyés par d'autres nœuds.
Ce paquet doit être envoyé sur tous les transports, pas seulement celui d'où provient le paquet, sinon les autres nœuds pourraient avoir une idée erronée du nombre d'auditeurs.
Lorsqu'un paquet a à la fois le bit de première tentative d'envoi et le drapeau d'intérêt, c'est comme un ACK implicite. Si nous envoyons une copie du paquet, nous n'avons pas besoin d'envoyer également un ACK pour nous ajouter au comptage d'intérêt.
Les répéteurs accusent réception en envoyant simplement une copie du paquet, lorsqu'il est marqué avec le drapeau de première copie, nous le comptons. Pour cette raison, les transports comme le WiFi doivent répéter même si cela n'a pas vraiment de sens.
Cela ne s'applique PAS aux transports de routage global, le routage global est géré séparément et n'est soumis à aucun type d'ACK ou de répétition, nous supposons que le serveur MQTT gère tout.
Les nœuds peuvent renvoyer un message plusieurs fois s'ils reçoivent moins de réponses que prévu.
Les nœuds ne doivent jamais s'attendre à plus de 6 répéteurs et 6 auditeurs de canal, même s'ils obtiennent plus de réponses, car le simple schéma d'ACK devient imprécis au-delà si la perte de paquets est modérée.
1 octet d'en-tête :
Toujours 0, le type de paquet est de contrôle, et ceux-ci ne sont ni routables ni répétables
1 octet d'en-tête 2 :
Identique à celui des paquets de données. Pas vraiment utilisé pour le moment
1 octet de sous-type :
CONTROL_TYPE_CHANNEL_ACKNOWLEDGE
Vous pouvez accuser réception en tant qu'auditeur de canal
afin que l'expéditeur sache combien il y en a.
4 octets d'ID de message :
juste les 4 premiers octets de l'IV aléatoire du paquet que nous accusons
Toutes les heures, quelques minutes avant l'heure, les nœuds doivent envoyer une annonce des canaux qui les intéressent.
Cela doit être envoyé avec les codes tournants pour l'heure suivante plutôt que l'heure actuelle, afin que les connexions puissent être établies à l'avance et que tout fonctionne même lorsque les heures sont désynchronisées.
Les nœuds se maillent via Bluetooth en utilisant un paquet de publicité étendue avec l'UUID de service d1a77e11-420f-9f11-1a00-10a6beef0001, et la charge utile étant simplement le format de paquet ci-dessus.
Les paquets BLE ne doivent jamais avoir le drapeau "première copie" défini, et nous ne comptons pas les répéteurs via BLE. La perte de paquets est tout simplement trop élevée pour tout schéma simple et évolutif auquel je peux penser.
Par conséquent, nous le traitons simplement comme un canal intrinsèquement avec pertes, que nous atténuons quelque peu en répétant les paquets jusqu'à 4 fois, ou jusqu'à ce que nous devions cesser de le faire pour pouvoir envoyer un autre paquet.
Tant que le nœud n'essaie pas d'envoyer plus d'un ou deux paquets par seconde, le schéma de répétition pure fournira une certaine fiabilité, et si nous dépassons cela, il ralentira pour ne pas saturer tout le monde.
Nous arrêtons également d'envoyer si nous voyons trop d'autres nœuds dans la même zone envoyant trop de copies du paquet.