mudhorn/meshtastic
1
0
Fork 0
mirror of https://github.com/meshtastic/meshtastic.git synced 2024-11-09 23:24:10 -08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

fix broken links

Browse source
This commit is contained in:
apt105 2021-04-25 23:10:18 +01:00
parent 4a73376a56
commit 774d851ad8
2 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
website/docs/legal/overview.md
View file

@ -9,7 +9,7 @@ slug: /legal
This project is still pretty young but moving at a pretty good pace. Not all features are fully implemented in the current alpha builds.
* We don't make these devices and they haven't been tested by UL or the FCC. If you use them you are experimenting and we can't promise they won't burn your house down ;-)
* The encryption implementation is good but see this list of [caveats](/software/other/crypto.md#summary-of-strengthsweaknesses-of-our-current-implementation) to determine risks you might face.
* The encryption implementation is good but see this list of [caveats](/docs/developers/device/encryption#summary-of-strengthsweaknesses-of-our-current-implementation) to determine risks you might face.
## Legal FAQ

2
website/docs/software/other/mesh-alg.md
View file

@ -26,7 +26,7 @@ After the preamble the 16 byte packet header is transmitted. This header is desc
- id (4 bytes): the unique (wrt the sending node only) packet ID number for this packet. We use a large (32 bit) packet ID to ensure there is enough unique state to protect any encrypted payload from attack.
- flags (4 bytes): Only a few bits are are currently used - 3 bits for for the "HopLimit" (see below) and 1 bit for "WantAck"
After the packet header the actual packet is placed onto the the wire. These bytes are merely the encrypted packed protobuf encoding of the SubPacket protobuf. A full description of our encryption is available in [crypto](crypto.md). It is worth noting that only this SubPacket is encrypted, headers are not. Which leaves open the option of eventually allowing nodes to route packets without knowing the keys used to encrypt.
After the packet header the actual packet is placed onto the the wire. These bytes are merely the encrypted packed protobuf encoding of the SubPacket protobuf. A full description of our encryption is available in [crypto](/docs/developers/device/encryption). It is worth noting that only this SubPacket is encrypted, headers are not. Which leaves open the option of eventually allowing nodes to route packets without knowing the keys used to encrypt.
NodeIds are constructed from the bottom four bytes of the macaddr of the bluetooth address. Because the OUI is assigned by the IEEE and we currently only support a few CPU manufacturers, the upper byte is defacto guaranteed unique for each vendor. The bottom 3 bytes are guaranteed unique by that vendor.