Hello ChirpStack team,
I’m using a Kerlink iStation gateway with the following data flow:
lorad > lorafwd (UDP, 127.0.0.1) > chirpstack-mqtt-forwarder (semtech enable) > ChirpStack Server (MQTT)
Everything works well, but I’m receiving tens of thousands of uplink packets per hour that are not valid LoRaWAN frames (invalid PHY, random payloads, etc.).
This creates huge MQTT traffic and unnecessary processing load on the central ChirpStack server and also a significant volume of data on the mobile network connection (since the gateway is connected via LTE).
Here’s an extract of my /etc/lorafwd.toml:
[filter]
crc.valid = true
crc.invalid = false
crc.none = false
lorawan.proprietary = false
lorawan.downlink = false
# Filter only LoRaWAN frames matching my NetID (CIDR notation)
lorawan.devaddr = [ "XX000000/7" ]
This works fine — it filters other networks’ LoRaWAN traffic —
but I still see a large number of "Invalid PHY payload" uplinks being passed from lorafwd to chirpstack-mqtt-forwarder.
Example logs:
lorafwd: <4> Invalid PHY payload size
chirpstack-mqtt-forwarder: Sending uplink event, uplink_id: 3565471015, topic: eu868/gateway/<EUI>/event/up
These packets have a valid CRC (so they pass lorafwd filtering ?)
but they are not decodable LoRaWAN frames
My questions :
1/ Is this setup correct and recommended for Kerlink iStation?
( no module chirpstack-concentratord for istation )
2/ Is there any way to drop invalid PHY / non-LoRaWAN frames earlier, before they are sent to the central MQTT broker?
3/ Would it be possible to add a filtering feature to chirpstack-mqtt-forwarder, e.g.:
[backend.filters]
drop_proprietary = true
drop_invalid_phy = true
Thanks for your help and for clarifying the expected behavior.
Filtering at the MQTT forwarder level would be a great improvement for noisy environments.
Best regards,
Steph
