eternityforest/lazymeshインターネット経由のグローバルルーティングを備えた概念実証のIoT/アマチュア無線メッシュネットワーク
OpenDHT プロキシをバックエンドとして使用し、ノードがインターネットを介して直接通信できるメッシュルーティングシステムです。非常に初期のプレアルファ版、概念実証であり、実際には動作しない可能性があります。
これは趣味やHAMのユースケース、およびより一般的な消費者向け/商用IoTの両方を対象としていますが、インターネットを置き換えたり、無指向性アンテナで広い高トラフィックエリアをカバーしようとするものではありません。
Meshtastic スタイルのネクストホップルーティングはありません。そのため LazyMesh という名前です。密集エリアでオフグリッドタイプのアプリケーションに使用する場合は、おそらく指向性アンテナと手動で調整されたルートIDが必要になります。
現時点ではこれが唯一の実際のアプリケーションです。Arduinoスケッチの例を開き、ユーザー名と強力なパスワードである秘密のチャンネルキーを入力して修正します。
Arduino シリアルモニターにメッセージを入力すると、他のすべてのデバイスとチャットできるようになります。
ノードが同じネットワーク上にあるか、両方にインターネットアクセスがあれば、メッセージは届くはずです。
Web Client にアクセスして、インターネット経由でMQTTを介してノードとチャットできます。ユーザー名を設定し、チャンネルを追加し、チャンネルパスワードを入力するだけです。チャンネル名は任意で、UIのラベリングにのみ影響します。
Read/Write data サンプルスケッチも試せます。これにより、データID 195が読み取り可能、データID 196が読み取りおよび書き込み可能になります。サイトにアクセスし、チャンネルの詳細を入力し、データリクエストダイアログを使用して全デバイスからID 196をリクエストします。
次に「set」をクリックして別の値に設定し、再度読み取ってみてください。
Web Client は現在 test.mosquitto.org を使用するようにハードコードされています。これは将来変更される予定です。
ノードは通信するために時刻を同期する方法が必要です。現在、信頼できるソースから時刻を受信したことがない場合、受信した任意のパケットから時刻を設定します。
これはリプレイ攻撃を許すセキュリティリスクになる可能性があるため、セキュリティが必要なデバイスは信頼できる時刻ソースを持つ必要があります。
一度時刻が初期設定されると、コードはシステム時刻を1日あたり最大1秒調整して他のノードと同期を保つため、同期がずれることは大きな問題にはならないはずです。
Lazymesh では、すべてがチャンネルです。ダイレクトメッセージはありません。必要な場合は、専用のプライベートチャンネルを作成してください。
チャンネルはパスワードで定義され、パスワードを知っていれば読み取りと書き込みの両方が可能です。
256のルート番号があります。すべてのパケットにはルート番号があり、リピーターは有効にしたルート番号に一致する場合のみリピートします。デフォルトでは、すべてがルート番号0で送信され、これはデフォルトで有効です。
これはリピーターのみに影響し、ノードは自分宛てであればどのメッシュルート番号でもリッスンします。
パケットペイロードはMessagePackの配列です。整数のデータIDとデータアイテムが交互に並びます。192～256はアプリケーション固有のメッセージ用に予約されています。
ID 32はテキストメッセージ用で、ユーザー名とコロンを前に付けることができます。
ID 2は一意のID用で、整数である必要があります。多くのアプリケーションではこれはまったく必要ないかもしれません。
メタデータ長バイトとNバイトのメタデータを追加します。
IVを作成するために、IV用に12バイトのランダムバイトを取得します。次に全体を暗号化します。先頭にIVを付け、末尾に4バイトの認証タグを追加します。
次にルーティングIDハッシュの最初の8バイトを取得し、16進数に変換します。
MQTTトピックは lazymesh_route_HEX になります。
トップレベルのトピックを使用していることに注意してください。これは、パブリックブローカーですべての lazymesh チャンネルを一度に購読するためにワイルドカードを使用できなくするためです。そうすると、全員を簡単にDoSできてしまうからです。
224.0.0.251:2221 にブロードキャストされる生のパケットのみ。
これに関しては何も確定していません!!!
All numbers are little-endian.
1 byte header:
2 bit packet type(Either 1 or 2, depending on if we want ACK)
3 bits TTL hops remaining
1 bit allow slow transport(LoRa etc)
1 bit allow global routing
1 bit was already global routed
1 byte header 2:
1 bit first send attempt:
Whenever we create a or recieve a packet, set this bit. After trying to send it,
clear it. This way, as long as we assume packet loss is low-ish, we can count the repeaters in the area
without extra overhead.
1 bit repeater bit:
Marks that this packet should be included when counting repeaters.
Set it if you would repeat the packet or one like it, even if you originated it.
1 bit interest bit:
If this is set, the node who sent it is directly interested in the channel,
not purely just a repeater. If first send is also set, it is treated as an
implicit ack
1 bit location enabled
If this bit is set, repeaters may add location metadata to the packets forwarded to the internet. This metadata must be encrypted with the routing ID as the key,
meaning nearby people could track you for 1 hour after you get out of range.
Not implemented anywhere at the moment.
5 reserved 0 bits
1 byte mesh route number
1 byte path loss accumulated:
5 bits total
3 bits last hop
Every hop is a point of path loss,
plus whatever extra cost heuristic the transport applies.
1 extra point of loss should be roughly the same "badness" as
10dbm extra loss on wifi.
16 bytes routing ID:
Changes every hour, derived from the channel PSK by a hash.
The PSK is just the 16 byte SHA256 of the password.
The routing ID changes hourly, and is the SHA256 of:
The letter 'cr'
The count of hours since 1970 as a 32 bit unsigned int
the PSK
8 Bytes random entropy:
Used as part of the IV for the cipher
4 bytes timestamp:
Also part of the IV, also prevents replay attacks
N bytes ciphertext:
AES-GCM encrypted.
The encryption key changes hourly, and is the SHA256 of:
The letter 'c'
The count of hours since 1970 as a 32 bit unsigned int
the PSK
6 bytes auth tag:
The last 6 bytes are the GCM tag
一部の実装ではこれを完全に無視する場合があります。
ACKは、上位プロトコル層がエンドツーエンドのACKを必要としない限り、純粋にホップごとです。ACKパケットはリピート、ルーティング、認証などは行われません。メッシュリピートの各ステップに独自の確認応答があり、元の送信者の視点では、fire and forget（撃ち放し）です。
Meshtastic や他のほとんどのプロトコルと同様に、このプロトコルは「準信頼性」です。すべてのネットワークと同様に、エッジケースによる障害が発生します。真の信頼性は上位レベルで実現する必要があります。
すべてのパケットに対して、その特定のチャンネルに興味を持つリスナーは、他のノードがすでに8つ以上のACKを送信したことを検出しない限り、チャンネル確認を一度だけ送信します。
このパケットは、パケットが到着したトランスポートだけでなく、すべてのトランスポートで送信する必要があります。そうしないと、他のノードがリスナーの数を誤って認識する可能性があります。
パケットに first send attempt ビットと interest フラグの両方が設定されている場合、それは暗黙のACKのようなものです。パケットのコピーを送信する場合、興味カウントに自分を追加するためのACKも送信する必要はありません。
リピーターは、パケットに first copy フラグが設定されている場合、パケットのコピーを送信することで確認応答します。これにより、WiFi などのトランスポートは意味がなくてもリピートする必要があります。
これはグローバルルーティングトランスポートには適用されません。グローバルルーティングは別途処理され、ACKやリピートなどの対象にはなりません。MQTTサーバーがすべてを処理することを前提としています。
ノードは、期待した応答よりも少ない応答を受け取った場合、メッセージを数回再送信する場合があります。
ノードは、たとえそれ以上の応答を受け取ったとしても、6つのリピーターと6つのチャンネルリスナー以上を期待してはいけません。なぜなら、単純なACK方式は、パケット損失が中程度になるとそれを超えると不正確になるからです。
1 byte header:
Always 0, packet type is control, and these are not routable or repeatable
1 byte header 2:
Same as on the data packets. Not really used at the moment
1 byte subtype:
CONTROL_TYPE_CHANNEL_ACKNOWLEDGE
You can acknowlege as a channel listener
so the sender knows how many there are.
4 byte message ID:
just the first 4 bytes of the random IV from the packet we are ACKing
毎時、正時の数分前に、ノードは自分が興味のあるチャンネルのアナウンスを送信する必要があります。
これは、現在の時間ではなく次の時間のローリングコードで送信されるべきです。これにより、事前に接続を設定でき、時刻が同期していない場合でもすべてが機能します。
ノードは、サービスUUID d1a77e11-420f-9f11-1a00-10a6beef0001 を持つ拡張アドバタイジングパケットを使用してBluetooth経由でメッシュを形成し、ペイロードは上記のパケット形式そのものです。
BLEパケットには「first copy」フラグを設定してはならず、BLE経由のリピーターはカウントしません。パケット損失が、私が考えられる単純でスケーラブルな方式には高すぎるためです。
したがって、本質的に損失の多いチャネルとして扱い、パケットを最大4回リピートすることで損失をある程度軽減します。または、他のパケットを送信するためにその必要性がなくなるまでリピートします。
ノードが1秒間に1～2パケット以上送信しようとしない限り、純粋なリピート方式である程度の信頼性が得られます。それを超えると、すべてを詰まらせないようにバックオフします。
また、同じエリアにパケットのコピーを送りすぎている他のノードが多すぎるのを検出した場合も送信を停止します。