Diy Electronics

As a supporter of this project I have a concern about packet replay attacks in the current Meshtastic protocol.  I would like to be set straight by someone with better knowledge, but I am concerned that I have found a vulnerability in the protocol which has an unfortunate security impact on many use cases involving machine control.

Here is the problem: A diligent search of the code finds nothing in the protocol which prevents saved encrypted packets from being replayed at a later time, any time after the FloodingPacketRouter has forgotten it at its default 10 minute interval.  In fact, this ability to store and replay encrypted packets is how basic mesh routing works and is also intrinsic to how the StoreAndForward thing works

But I can find no defense in receiving nodes to a replay from messages that came from before 10 minutes ago.

I have confirmed that this “stored packet replay” attack is possible ex tempore via trivial modifications to the firmware which, of course, I shall not release.  So don’t ask.  You can replay a message to a node 10 minutes after it has received it and it will accept it as new and act on it again.

Here is why I believe this is a concern, especially for tele-command, IOT, and other machine applications of Meshtastic

Suppose NodeA uses the sensor module to send a sensor change message on an encrypted private channel, perhaps tell another node to open a gate when a car is detected.  NodeB receives the message and opens the gate.  Many Meshtastic use cases fall into this M2M/IOT category.

Suppose a malicious node NodeMal nearby captures that encrypted message.  Even without being able to decrypt the message, its capture is enough to support a no-brainer replay attack.  After the Flooding Packet Router timeout of 10 minutes, that message could be re-emitted by NodeMal.  NodeB would have no way to know that it was a replay.  In other words, NodeB would perform whatever procedure it uses to open the gate every time NodeMal sends the malicious replay.

If this line of analysis is correct, and while I have experimentally verified it I stand to be corrected by more knowledgable people, there is nothing in the current Meshtastic protocol that would prevent undetected packet replay manipulation of any tele-commanded node using previous packets replayed.  Including ones captured internationally via MQTT at an indefinite time before.

And this is the core of the concern.  It’s a pretty precarious state of affairs for anything electronically connected to a Meshtastic node.  Any message ever sent to control your device could be intercepted, anywhere in the mesh, anywhere on MQTT, and replayed into your device at a time not of your choosing, by anyone anywhere in the world.

I am a big fan of this project.  I have direct, personal experience that packets can be replayed with trivial modifications to the firmware.  If this line of analysis is true,  there are significant caveats on using Meshtastic in real-world applications.  it would be good to hear more from the developers on their thoughts about this, especially their views on this potential issue, and how the project roadmap will address it

I would welcome further information, and discussion, and I am prepared to be refuted, but mostly I would like to hear from the Meshtastic team on their thoughts.

Hello, our team has had no machines other than the basic shop tools and a poor quality 3d printer, but we have gotten a $10,000 budget and I have been tasked with getting everything done. I am looking for recommendations. Our main goals are safety, and to have a 4 x 4 foot minimum work area. Any suggestions are greatly appreciated.

Something to share with the group - I built a simple Meshtastic Discord Bridge bot:

I keep my Meshtastic node on at home - this allows me to read and send messages to the mesh through Discord where ever I am. It's in a "just got it working" state - pretty primitive, missing message delivery confirmation, but I've been using it for a few days - seem to work, may be a useful.

Hey Everyone!

I am releasing the files on for our FIRST Tech Challenge Robotics Training Platform! This platform uses the REV control system used in the FTC competition. These files will come with 3d printable clips to attach REV sensors. The profile for the clips is on as well so we want to see attachments the FTC community will make to turn our little bot into whatever you need! If you have any questions let me know! If you make some attachments or want to show of your cool print feel free to message me a picture and I can add it to the FTC RTP Instagram, and link to the model page for others to download!

Here is the model page:

P.S. Not sure if this is considered solicitation, this is a free file for 3D printing, if you would like there is a link to "buy me coffee" but that is it. Tried to contact the mod team to approve my post, but received no answer, so if this is not allowed I apologize.

Based on this there is the requirement that any panels imported by June 6,2024 will need to be used by the person importing within 180 days or they will have to retroactively pay the tariff. Does it mean these panels sold to DIY would not qualify?