Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit message transport to 3x messages per minute per device? #8

Open
samuk opened this issue Feb 12, 2020 · 2 comments
Open

Limit message transport to 3x messages per minute per device? #8

samuk opened this issue Feb 12, 2020 · 2 comments

Comments

@samuk
Copy link

samuk commented Feb 12, 2020

If I wanted to disrupt a Disaster radio network I'd set up a node that broadcasts a message every 200ms to all other nodes in the network. This would probably cause the network to grind to a halt and drop loads of messages.

If each node was limited to sending one message every 20 seconds I'd have to buy loads more devices to achieve the same.

As I understand it the Mac address is derived from the Semtech on-chip UUID and not that trivial to spoof?

This could also be implemented on the client-side, so it's not a surprise to the user that the messages are dropped, but it would also need to be in the routing logic as the firmware can be re-written.

I realise I can still build my 200ms broadcast device, but at least the disruption is limited to nodes that can hear me, and not the rest of the network.

@cyclomies
Copy link

cyclomies commented Apr 23, 2020

How about limiting messages forwarded or rebroadcast, from a particular node, with a increasing time between messages (after a certain threshold)? The same way we do limit brute-forcing our passwords: you can try the first times without a delay, but eventually the delay is increased by doubling the delay.

This way, the nodes would not be limited/fixed to a certain time intervals, and could forward packets as soon as possible. If all nodes would respect the same rules, defining maximum amount of packets sent within a certain time frame thresholds, this shouldn't cause any constrictions on the network.

Actually, duty cycles are already in place, with a fixed maximum airtime. Therefore, it might be rather easy to add a node specific increasing time buffer for outgoing packets.

@samuk
Copy link
Author

samuk commented Apr 24, 2020

Yeah this sounds like a good approach to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants