RAK7268CV2 filter proprietary Lora payloads

LPWAN Industrial Gateways / Concentrators
1

Good morning and happy new year!

I currently have several RAK7268CV2 LTE hauled gateways which are configured to send messages to a Chirpstack cloud service using the Package Forwarded configuration.

I also put a filter on several OUI and a NetID filter in order to reduce network consumption.

My only problem is that I see plenty of Proprietary payload on Chirpstack that are sent by the gateways which are totally useless to me but using a lot of bandwidth (almost 70% of it unfortuntately).

As per my understanding, those are not filtered by the gateway since they both don’t have a valid DevAddr (and thus the NetID filter won’t work) and they are not Join requests (so the OUI filter won’t apply).
For those reason they are broadcasted to Chirpstack.
I don’t really understand why this is the default behaviour, I’d expect them to be skipped since they are not valid LoraWAN messages in the first place, but nevertheless they are forwarded and thus use my costly bandwidth.

Is there a way to limit the forwarding of those messages? I’m currently using the 2.2.14 firmware version.

I attach a screenshot of some of those messages in the Chirpstack lorawan frames.

Thank you very much for your help and disposal.

image

Have a nice day
Giacomo Alberini

2

This is the configuration of the filters in the gateway:

image
image1212×572 20.9 KB

3

Hi @giacomoalberini,

Could you share syslogs when the gateway is receiving the proprietary packets? As far as I know, gateways only accept valid LoRaWAN join requests even if they have a DevAddr not listed on the white list.

And I would appreciate it if you confirmed that your ChirpStack server has the network ID 16.

4

Hi @JaeHwan.Jin,

Thanks for your kind response.
First of all, yes I can confirm that the Chirpstack server has NetID 16 (not Network ID, but only the NetID part is 16, but the filter works).

Unfortunately I have several gateways deployed and just one available for getting the syslog and the proprietary messages are out of the syslog now available window (morew than 1 hour ago).
Now I’m waiting for another proprietary message to arrive and I’ll share the syslog with you.

For now, I can attach the message data from Chirpstack, maybe from there you can find something useful.

{ "phy_payload": { "mhdr": { "f_type": "Proprietary", "major": "LoRaWANR1" }, "mic": null, "payload": "07944591f39c51914edacb8847f258533399c0f07f1bcab1da2dac3813d9a2c092aa6c0af631dcfb8dc0cab41384bd761888fd" }, "rx_info": [ { "channel": 7, "context": "XMtK7g==", "crcStatus": "CRC_OK", "gatewayId": "ac1f09fffe1f204f", "gwTime": "2026-01-07T06:58:54.372140+00:00", "location": { "altitude": 50, "latitude": 48.50793, "longitude": -35.08763 }, "nsTime": "2026-01-07T06:58:54.381204686+00:00", "rfChain": 1, "rssi": -111, "snr": -18.5, "uplinkId": 27909 } ], "tx_info": { "frequency": 868500000, "modulation": { "lora": { "bandwidth": 125000, "codeRate": "CR_4_5", "spreadingFactor": 12 } } } }

Other proprietary message:

{ "phy_payload": { "mhdr": { "f_type": "Proprietary", "major": "LoRaWANR1" }, "mic": null, "payload": "07944591f39c51914edacb8847f258533399c0f07f1bcab1da2dac3813d9a2c092aa6c0af631dcfb8dc0cab41384bd761888fd" }, "rx_info": [ { "channel": 7, "context": "XMtK7g==", "crcStatus": "CRC_OK", "gatewayId": "ac1f09fffe1f204f", "gwTime": "2026-01-07T06:58:54.372140+00:00", "location": { "altitude": 50, "latitude": 48.50793, "longitude": -35.08763 }, "nsTime": "2026-01-07T06:58:54.381734424+00:00", "rfChain": 1, "rssi": -111, "snr": -18.5, "uplinkId": 27909 } ], "tx_info": { "frequency": 868500000, "modulation": { "lora": { "bandwidth": 125000, "codeRate": "CR_4_5", "spreadingFactor": 12 } } } }

As you can see those two messages are neither Join or Uplink with correct DevAddr.

Thanks a lot
Giacomo

5

Hi @giacomoalberini,

I’m wondering if you got the syslogs. Are there any updates?