You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: