Is it possible to force a sensor to send via one specific gateway?
Or in other words: If 2 gateways in range of a node, can forbid in a way to send via gateway 2 and only send via gateway 1?
If this is not possible, can I exclude a Sensor in the (App-)Server, when he was sending via gateway 2?
Best Regards
No this is not possible (currently). Could you explain the use-case?
I think about a commercial use-case.
If I have a client A and client B nearby, I don’t want that the sensors of client A can send through the gateway B.
Also other sensors should not be able to send through these gateways.
I’m also thinking about an ‘attack’ where someone brings a big amount of sensors nearby the gateways. So they are not registred at the server, but will block all other traffic with their join requests (which will never be accepted).
Another question:
How long will an unregistered sensor try to join the network?
Endless?
Or is somwhere a timeout or counter which blocks/pauses the join requests? (on gateway/server-side)
In a useful case this should be managed by the software on the node, right?
Have anyone here experience with this cases?
Hi,
you can (but actually you should not) do tricks on the gateway. Anyhow the radio frontend will still process the uplinks and lower the throughput of the gateway.
@tkiraly Thanks for your answer. I thought about a possibility, where the packet forwarder could be modified, but this is not the way it should be done.
@hasiflo, the gateway is a ‘dumb’ device which basically forwards every valid LoRa packet it receives to the server, irrespective if it is originating from it’s own ‘cloud’ of devices or from other clouds. This means for a private LoRa network that the gateway(s) will also be forwarding traffic from other networks like incumbents and TTN, and that your server will need to be able to handle much more traffic than you are actually generating with your own devices.
That depends on the implementation of the software on the devices. I think most devices will keep trying to join indefinitely, although may turn down the frequency of requests.
Since the network does not respond at all to an invalid join request, the device itself cannot determine whether its keys have turned invalid or whether it is simply out of reach of the network.
@rharte thanks for your contribution
So, it is true, that every gateway can be easily blocked with the right amount of “enemy-nodes”?
Yes, it would be quite easy to design a ‘hostile’ node which continuously keeps sending with SF12, and which does not listen to MAC commands to tone down. And you would just need one of these for every channel on the gateway. This would not fully block the gateway but absorb a considerable amount of its capacity.