This adds a [backend.filters] configuration section under which it is possible to configure the prefix-filters for DevAddr (data uplink) and JoinEUIs (join-requests).
Improvements
Time fallback
This adds a time_fallback_enabled configuration option to the semtech_udp section. If enabled and no RX time is provided by the packet-forwarder, then the ChirpStack MQTT Forwarder server-time will be used as fallback.
Build improvements
The provided pre-compiled binaries are fully static and based on musl libc. This removes the need to compile against a very old verion of glibc to stay compatible with old gateway firmwares.
I know how to uplink filtering with NetID, but what is the way to do it with DevAddr? How can we define the rules of DevAddr filtering? Does Chirpstack assign DevAddr in a specific way?
The GitHub issue has more info on the topic (it looks like the configuration section on the Docs site still needs to be updated):
In summary, you can filter with a bitmask, allowing for more fine-graned filtering than just NetID. The Backend Interfaces spec has documentation on how DevAddr is built from the NetID:
I have just pushed a new documentation update. In short, these are the configuration options for DevAddr and JoinEUI filters:
# DevAddr prefix filters.
#
# Example configuration:
# dev_addr_prefixes=["0000ff00/24"]
#
# The above filter means that the 24MSB of 0000ff00 will be used to
# filter DevAddrs. Uplinks with DevAddrs that do not match any of the
# configured filters will not be forwarded. Leaving this option empty
# disables filtering on DevAddr.
dev_addr_prefixes=[
]
# JoinEUI prefix filters.
#
# Example configuration:
# join_eui_prefixes=["0000ff0000000000/24"]
#
# The above filter means that the 24MSB of 0000ff0000000000 will be used
# to filter JoinEUIs. Uplinks with JoinEUIs that do not match any of the
# configured filters will not be forwarded. Leaving this option empty
# disables filtering on JoinEUI.
join_eui_prefixes=[
]
Correct, and the NetID based filtering would work in the same way but in that case the bitmask would be derived from the NetID (based on the specification you linked to).
This allows you to filter on a sub-set of DevAddrs within a NetID. E.g. you can setup ChirpStack (v4) to only use a sub-set of the DevAddr space within a NetID instead of the full DevAddr range (e.g. you are leasing a range or you have different instances, each using a range within your NetID).
Hello ,
I saw in the configuration file that there is no more parameters available to set the interval between 2 executions and the timout for dynamic metadata commands (compare to gateway bridge).
Does it mean that it works differently (based on event like reconnection instead of interval)?
These commands will be executed on generating the stats. In case of the GW Bridge, the dynamic meta-data would be retrieved every interval and cached. The MQTT Forwarder implementation is a lot simpler.
In general, these meta-data commands should return immediately (e.g. board temperature, public IP address, serial numbers etc…).
For public IP address on LTE, as we call an external service (like icanhazip.com), this could lead to higher data consumption (except if a CLI command exists to get it on the Kerlink or Multitech gateways).
Why not create a shell script which caches the output into a file? In case the file is older than X time do a new request? Alternatively, you could setup a cronjob to retrieve the external IP, and configure the MQTT Forwarder with cat /tmp/public_ip.txt or something alike
I think it is better to let the command handling caching, timeouts etc… it keeps the MQTT Forwarder implementation simpler + different commands might need to run in different intervals (e.g. the external IP you only might want to retrieve every hour, where the system-time, uptime, etc… information you want to get on generating the stats).
,