This option does two things:
1) In case the passive-roaming agreement is not state-less, it will
trigger the validation of MIC (this was already implemented at the
roaming-session retrieval, but never used).
2) On PRStartAns, it will return the NwkSKey / FNwkSIntKey to the
requester (such that the MIC validation can be performed).
For state-less passive-roaming, it is recommended to leave this option
set to false, such that no session-keys are exposed.
In this case, we return the (primary) NetID of the ChirpStack instance.
Supporting the HomeNSReq is useful in the case the roaming ChirpStack
instances are setup to resolve the servers using DNS. In case of OTAA,
the fNS resolves the JoinEUI to a hostname to which it must make the
HomeNSReq. This returns the HNetID, which then can be used to resolve
the hostname of the hNS to which the join-request must be forwarded.
This makes it a lot easier to iterate over the intervals, as we no
longer have to take into account DST changes that could either result in
an invalid or ambiguous date, or not incrementing by the expected
interval. E.g. incrementing by 1 day resulting in a 23 hour increment
because or DST change.
On returning the metrics, we try to convert the NaiveDateTime back into
a DateTime<Local>, failing that, we skip it rather than failing on it.
Closes#415.
In general ChirpStack is configured with a rx1_delay configuration
matching the network latency (e.g. on cellular, one might want to set
this to rx1_delay=3). However, this does not take into account a
possible latency of the end-application. Handling the uplink and
enqueueing a downlink might take more time than the configured rx1_delay
(and get_downlink_data_delay) allows.
This option makes it possible to increase the RX1 Delay in the
device-profile. If the RX1 Delay has between increased relative to
the system default, then the get_downlink_data_delay will be
incremented with the same amount of seconds.
This fallback was already implemented for reading the private key when
generating MQTT client-certificates, but it was not used when reading a
private key for connecting to the MQTT broker.
While it is recommended to use PKCS#8 private-keys, this will perform an
auto conversion for RSA PKCS#1 and EC P256 SEC1 private-keys to PKCS#8.
This aligns the multicast class-b ping-slot configuration with the way
how it is configured in the device-profile. This deprecates the
class_b_ping_slot_period field in favor of the class_b_ping_slot_nb_k
field, which should be a value between 0 - 7 (this is defined and
explained by the LoRaWAN specification).
Closes#255.
This refactors the multiple update functions into a single function
accepting a change-set struct. This also adds a sanity check to make
sure we are not updating the gw loc when lat / lon / alt are all set to
0.
This migrates the device-sessions from Redis into PostgreSQL. This fixes
a performance issue in case the same DevAddr is reused many times
(e.g. devices rejoining very often or a NetID with small DevAddr space).
There were two issues:
The Redis key containing the DevAddr -> DevEUIs mapping could contain
DevEUIs that no longer used the DevAddr. This mapping would only expire
from the Redis database after none of the devices would use the DevAddr
for more than the configured device_session_ttl.
The other issue with the previous approach was that on for example a
Type 7 NetID, a single DevAddr could be re-used multiple times. As each
device-session could be stored on a different Redis Cluster instance,
there was no option to retrieve all device-sessions at once. Thus a high
re-usage of a single DevAddr would cause an increase in Redis queries.
Both issues are solved by moving the device-session into PostgreSQL
as the DevAddr is a column of the device record and thus filtering on
this DevAddr would always result in the devices using that DevAddr, as
well all device-sessions for a DevAddr can be retrieved by a single
query.
Note that to migrate the device-sessions, you must run:
chirpstack -c path/to/config migrate-device-sessions-to-postgres
A nice side-effect is that a PostgreSQL backup / restore will also
restore the device connectivity.
Closes#362 and #74.
This merges the deduplication_put and deduplication_locked Redis queries
into a single pipelined query. Simulating 400 uplinks / seconds through
3 gateways (thus 1200 messages / second), and an artificial TCP latency
of 5ms between ChirpStack <> Redis, this reduces the
storage_redis_conn_get_duration_seconds_sum metric by about 50%.
What we are trying to solve here is that under high (simulated) load, we
exhaust the Redis connection pool. This situation gets worse when there
is a significant latency between ChirpStack <> Redis, because the query
takes longer to complete and is reserved from the pool for a longer
time. The result can be that during the de-duplication process, the key
containing the uplink set has already expired before the
deduplicate_collect function is able to get a Redis connection from the
pool.
This query merge is a quick win, because each uplink can be received by
N gateways, thus this merge saves N Redis queries per uplink.
This data is useful when debugging connection-pool size related issues.
E.g. when more connections are requested than the connection pool allows
then this will result in a longer wait time.
