Large amount of unknown transmissions

On many of our gateways, we receive a lot of unknown traffic with Device Addresses that we do not recognize. In this particular case, up to 4000+ transmissions where we would expect around 100-200 from our connected sensors. All sensors work perfectly well and do not exhibit suspicious behavior as far as we can tell. As we deploy some gateways with LTE connection, this quickly uses up all the available data.

Is there a way to prevent this unwanted traffic or find out where it is coming from? I am not even sure this traffic is originating from ordinary LoRa devices.


Example payload of unknown device:

Your gateway is receiving all the uplinks in the area, and it can’t determine whether it’s an “authorized” frame until the data reaches the NS.

The only thing you can do is to filter the traffic by network ID (thanks to the gateway-bridge), but even this will not stop the join requests and the traffic from other private networks with a similar NetID (in theory 0 or 1).

1 Like

Just to clarify for myself: This would only work when the Gateway Bridge is installed on the Gateway itself, correct?

Yes, correct. This way, the frame with other NetID are blocked at the gateway level.

1 Like

I have now set up the server for TLS and configured a gateway (Dragino DLOS8) with the Gateway Bridge. Everything seems to work o.k. but I noticed a huge decrease in bandwidth when connecting to the gateway. Disabling the Gateway Bridge fixes this issue. We are using the OpenVPN build from Dragino to access the gateway.

Any idea why this is the case?

1 Like

Followup question concerning the NetId Filter: Is it possible to whitelist NetIds? From the documentation it appears as if we have to block each NetId individually.

The Gateway Bridge filtering (recently added to MQTT Forwarder in a different form) is only a whitelist.

Great, that is good to know!

Everything seems to be working now, except that Frames and Events are not showing up in the Application. The gateway is shown under last seen, however.

I can see that the uplinks show up in Mosquitto correctly, but the NS seems to throw an error:

> ERROR chirpstack::gateway::backend::mqtt: Processing gateway event error: unknown field crcStatus, expected one of gatewayId, uplinkId, time, timeSinceGpsEpoch, fineTimeSinceGpsEpoch, rssi, snr, channel, rfChain, board, antenna, location, context, metadata at line 1 column 376 topic="eu868/gateway/a84041ffff1f7d30/event/up" qos=0

Here is the Payload as shown in Mosquitto:

> {
>   "phyPayload": "AAABAAAAAACgBE+D0aNBQKiAZRu6LVQ=",
>   "txInfo": {
>     "frequency": 868500000,
>     "modulation": {
>       "lora": {
>         "bandwidth": 125000,
>         "spreadingFactor": 12,
>         "codeRate": "CR_4_5"
>       }
>     }
>   },
>   "rxInfo": {
>     "gatewayId": "a84041ffff1f7d30",
>     "uplinkId": 23982,
>     "time": "2023-06-09T08:24:39.290907Z",
>     "timeSinceGpsEpoch": "1370334296.290s",
>     "rssi": -55,
>     "snr": 6,
>     "channel": 2,
>     "rfChain": 1,
>     "context": "EGU4nA==",
>     "crcStatus": "CRC_OK"
>   }
> }

I also have a Gateway Bridge running directly on the server, data that comes through that way does not have the key “crcStatus”.

I am using v. 4.0.4 Gateway-Bridge and Chirpstack v. 4.0.4. I Tried using the latest Gateway Bridge (v 4.0.8) as well, same error.

For anyone facing a similar issue, I managed to solve this by updating Chirpstack to the current version (v. 4.3.2) and using the most recent Gateway-Bridge (v. 4.0.8) on both server and gateway.

The problem originates from the Gateway-Bridge 4.0.4 update, where the crc_status field was added back to UplinkRxInfo. I thought I could solve this issue by using older versions of the Gateway Bridge but they were incompatible with the packet forwarder on my gateway (Dragino DLOS8). After the update, everything works fine.

1 Like