Repository navigation
[Feature request] protection against replay attacks #3265
Description
Hey all,
For the past week there has been a continuous replay attack in The Netherlands.
Someone has been spoofing messages and sending them out again. This has caused some people to implement custom firmware on their repeaters to filter out 1 byte. But more worryingly, people are quitting the hobby and taking their repeaters offline.
Is it possible to build in protection against this? The public channel and some other hashtag channels like #nl cannot be used anymore since for every message you send, you get it back five or more times.
You can check the replay attack here: https://mc-spamdetector.nl/messages. It sometimes stops during the night but always starts up again.
Combined with the DOS attacks (PM flood spam) that take out the entire network for hours every day since the past 5 months, Meshcore is getting pretty unusable sadly.
Activity
isidis commentedon Sep 8, 2026
This feature request is really a must. Forks are already in place due to this issue. We would preferably see this option in repeater and client firmware. At least to block 1-byte messages.
Torisaz commentedon Sep 17, 2026
so not a dev, no one has answered. so maybe this will help.
as far as i can see when you wade through the code. the stuff u need has been written for a while now
looking back .. since 1.14
you just have to turn it on with cli
Usage: - get loop.detect - set loop.detect
Parameters: - state: - off: no loop detection is performed - minimal: packets are dropped if repeater's ID/hash appears 4 or more times (1-byte), 2 or more (2-byte), 1 or more (3-byte) - moderate: packets are dropped if repeater's ID/hash appears 2 or more times (1-byte), 1 or more (2-byte), 1 or more (3-byte) - strict: packets are dropped if repeater's ID/hash appears 1 or more times (1-byte), 1 or more (2-byte), 1 or more (3-byte)
flackrat commentedon Oct 17, 2026
In case it helps operators on openHop repeaters: SpamGuard (an openHop plugin I maintain) now holds back replayed channel messages. When a message turns up again under the same name with a badly wrong clock, or under a cut-short copy of the name, further copies from that name aren't passed on, while the original and anything new still go out. Copies under other names and one name repeating itself are already handled. It doesn't help with replayed direct messages, and the first replayed copy still gets through, but it cuts the repeats on Public a lot: https://github.com/flackrat/openhop-spamguard