eternityforest/lazymesh인터넷을 통한 글로벌 라우팅이 가능한 IoT/햄 무선 메시 네트워크의 개념 증명
백엔드로 OpenDHT 프록시를 사용하여 노드가 인터넷을 통해 직접 통신할 수 있는 메시 라우팅 시스템입니다. 매우 초기 프리 알파, 개념 증명 단계이며, 실제로 작동하지 않을 수도 있습니다.
이 시스템은 취미/HAM 사용 사례와 보다 일반적인 소비자/상업용 IoT 작업 모두를 대상으로 하지만, 구체적으로 인터넷을 대체하거나 전방향 안테나로 대규모 고트래픽 지역을 커버하려고 시도하지 않습니다.
Meshtastic 스타일의 다음 홉 라우팅이 없으므로 LazyMesh라는 이름이 붙었습니다. 밀집 지역에서 오프그리드 유형 애플리케이션에 사용하려면 지향성 안테나와 수동으로 조정된 라우트 ID가 필요할 것입니다.
현재로서는 이것이 유일한 실제 애플리케이션입니다. 예제 Arduino 스케치를 열고 사용자 이름과 강력한 비밀번호여야 하는 비밀 채널 키로 수정하세요.
Arduino 시리얼 모니터에 메시지를 입력하면 다른 모든 장치와 채팅할 수 있습니다.
노드가 동일한 네트워크에 있거나 둘 다 인터넷에 접속할 수 있는 한 메시지는 전달되어야 합니다.
웹 클라이언트를 방문하여 인터넷에서 MQTT를 통해 노드와 채팅하세요. 사용자 이름을 설정하고 채널을 추가한 다음 채널 비밀번호를 입력하기만 하면 됩니다. 채널 이름은 무엇이든 될 수 있으며 UI의 레이블에만 영향을 미칩니다.
읽기/쓰기 데이터 예제 스케치도 시도해 볼 수 있습니다. 이 스케치는 데이터 ID 195를 읽기 가능으로, 데이터 ID 196을 읽기 및 쓰기 가능으로 노출합니다. 사이트로 이동하여 채널 세부 정보를 입력하고 데이터 요청 대화상자를 사용하여 모든 장치에서 ID 196을 요청하세요.
그런 다음 "set"을 클릭하고 다른 값으로 설정한 후 다시 읽어보세요.
웹 클라이언트는 현재 test.mosquitto.org를 사용하도록 하드코딩되어 있으며, 이는 향후 변경될 예정입니다.
노드는 통신을 위해 시간을 동기화할 방법이 필요합니다. 현재, 신뢰할 수 있는 소스로부터 시간을 수신한 적이 없는 경우, 노드는 보이는 임의의 패킷에서 시간을 설정합니다.
이는 재전송 공격을 허용하는 보안 위험이 될 수 있으므로, 보안이 필요한 장치는 신뢰할 수 있는 시간 소스를 가져야 합니다.
시간이 초기에 설정되면, 코드는 다른 노드와 동기화를 유지하기 위해 하루에 최대 1초까지 시스템 시간을 조정하므로, 동기화가 어긋나는 것은 큰 문제가 되지 않을 것입니다.
Lazymesh에서 모든 것은 채널이며, 직접 메시지는 없습니다. 원한다면 전용 비공개 채널을 만드세요.
채널은 비밀번호로 정의되며, 비밀번호를 알면 읽기 및 쓰기 액세스가 가능합니다.
256개의 라우트 번호가 있습니다. 모든 패킷에는 하나가 있으며, 리피터는 일치하는 라우트 번호가 활성화된 경우에만 반복합니다. 기본적으로 모든 것은 라우트 번호 0으로 전송되며, 이는 기본적으로 활성화되어 있습니다.
이는 리피터에만 영향을 미치며, 노드는 직접 자신을 위한 것이라면 모든 메시 라우트 번호를 수신합니다.
패킷 페이로드는 MessagePack 배열입니다. 정수 데이터 ID와 데이터 항목이 번갈아 나타납니다. 192-256은 애플리케이션별 메시지용으로 예약되어 있습니다.
ID 32는 텍스트 메시지용이며, 사용자 이름과 콜론을 접두사로 붙일 수 있습니다.
ID 2는 고유 ID용으로 사용되며, 정수여야 합니다. 많은 애플리케이션에서 전혀 필요하지 않을 수도 있습니다.
메타데이터 길이 바이트와 N 바이트의 메타데이터를 추가합니다.
IV를 생성하려면 12개의 임의 바이트를 IV로 사용합니다. 그런 다음 전체를 암호화합니다. 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 패킷은 반복되거나 라우팅되지 않으며 인증되지도 않습니다. 메시 반복의 모든 단계는 자체 확인(acknowledgement)을 가지며, 원래 송신자의 관점에서는 발사 후 망각(fire and forget)입니다.
Meshtastic 및 대부분의 다른 시스템과 마찬가지로 프로토콜은 "반신뢰성(semi-reliable)"이며, 모든 네트워크와 마찬가지로 실패를 유발하는 예외 상황이 있습니다.
실제 신뢰성은 더 높은 수준에서 수행되어야 합니다.
모든 패킷에 대해 해당 특정 채널에 관심 있는 모든 수신자는 (다른 노드가 이미 8개 이상의 ACK를 보냈다고 감지하지 않는 한) 정확히 한 번 채널 확인(channel acknowledge)을 전송합니다.
이 패킷은 패킷이 온 전송 방식뿐만 아니라 모든 전송 방식으로 전송되어야 합니다. 그렇지 않으면 다른 노드가 수신자 수를 잘못 파악할 수 있습니다.
패킷에 첫 번째 전송 시도 비트와 관심 플래그가 모두 설정된 경우, 이는 암시적 ACK와 같습니다. 패킷의 복사본을 보내는 경우, 관심 카운트에 자신을 추가하기 위해 ACK를 별도로 보낼 필요가 없습니다.
리피터는 패킷의 복사본을 보내는 것으로 확인하며, 첫 번째 복사본 플래그가 설정된 경우 이를 카운트합니다. 이러한 이유로 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
매시간 정각 몇 분 전에 노드는 관심 있는 채널의 알림(announce)을 보내야 합니다.
이는 현재 시간이 아닌 다음 시간의 롤링 코드로 전송되어야 합니다. 그래야 연결이 미리 설정되고 시간이 동기화되지 않은 경우에도 모든 것이 작동합니다.
노드는 서비스 UUID d1a77e11-420f-9f11-1a00-10a6beef0001을 사용하는 확장 광고 패킷을 통해 블루투스로 메시를 구성하며, 페이로드는 위의 패킷 형식 그대로입니다.
BLE 패킷에는 절대 "첫 번째 복사본" 플래그가 설정되어서는 안 되며, BLE를 통한 리피터는 카운트하지 않습니다. 패킷 손실이 제가 생각할 수 있는 간단하고 확장 가능한 방식으로는 너무 높기 때문입니다.
따라서 우리는 이를 본질적으로 손실이 많은 채널로 처리하고, 패킷을 최대 4번까지 반복하거나 다른 패킷을 보내기 위해 반복을 중단해야 할 때까지 반복하여 어느 정도 완화합니다.
노드가 초당 1~2개 패킷 이상을 보내려고 하지 않는 한, 순수 반복 방식은 어느 정도 신뢰성을 제공하며, 그 이상으로 가면 모든 것을 정체시키지 않도록 백오프(back off)합니다.
또한 동일한 지역에 있는 다른 노드가 패킷의 복사본을 너무 많이 보내는 것을 너무 많이 보게 되면 전송을 중단합니다.