Fix OTAA key mapping for LoRaWAN 1.1.x devices#298
Open
MortenGuldager wants to merge 1 commit into
Open
Conversation
ChirpStack's DeviceKeys protobuf has version-dependent semantics: * LoRaWAN 1.0.x: nwk_key holds the single root AppKey, app_key is unused. * LoRaWAN 1.1.x: nwk_key holds the root NwkKey, app_key holds the root AppKey. The backend always wrote the user's OTAAapplicationKey into ChirpStack's nwk_key field regardless of device-profile mac_version, so 1.1.x devices ended up with their AppKey in the NwkKey slot and no AppKey set. The read path made the symmetric mistake. Changes: * Add OTAAnetworkKey to CreateLoRaWANSettingsDto and LoRaWANDevice; add migration AddedOTAANetworkKey1779744000000. * mapDeviceKeysToChirpstack and activateDeviceWithOTAA now take macVersion and route keys version-correctly. For 1.0.x, behaviour is unchanged. * doActivationByOTAA looks up the device profile's macVersion and passes both keys through. * mapActivationAndKeys reads both nwk_key and app_key for 1.1.x; for 1.0.x, behaviour is unchanged. * CSV import/export schema gets the new OTAAnetworkKey column.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
For LoRaWAN 1.1.x devices havner brugerens AppKey i ChirpStacks
nwk_key-felt, og det rigtigeapp_key-felt sættes aldrig. Symptomet er at devices ikke kan joine fordi network- og application-nøglerne reelt er byttet om i ChirpStack.ChirpStacks
DeviceKeys-protobuf har versionsafhængig semantik:nwk_keyapp_keyOS2IoT skrev altid
OTAAapplicationKeyind inwk_keyuden at se på device-profilensmacVersion(mapDeviceKeysToChirpstack,chirpstack-device.service.ts:207). Læsestien lavede den symmetriske fejl.Løsning
OTAAnetworkKeytilføjet til DTO + entity + ny migration (kun udfyldt ved 1.1.x — frontend skjuler feltet ved 1.0.x).mapDeviceKeysToChirpstackogactivateDeviceWithOTAAtager numacVersionind og mapper version-afhængigt. 1.0.x-adfærd uændret.doActivationByOTAAslår device-profilen op viaDeviceProfileServiceog videregivermacVersion+ begge nøgler.mapActivationAndKeysudfylder bådeOTAAapplicationKeyogOTAAnetworkKeyfor 1.1.x ved læsning.OTAAnetworkKey-kolonne.Test (manuel, lokal docker-compose)
mac_version = 5(LoRaWAN 1.1.0) og en medmac_version = 3(1.0.3).OTAAapplicationKey=aaaa…aaogOTAAnetworkKey=bbbb…bb. Verificer i ChirpStack via gRPC:OTAAapplicationKey=cccc…cc.Migration af eksisterende data
Migrationen tilføjer kun den nye kolonne. Eksisterende 1.1.x-rækker har brugerens "AppKey" gemt i ChirpStacks
nwk_key, ogOTAAnetworkKeypå OS2IoT-siden erNULL. Næste gang en bruger åbner et 1.1.x device i frontend vil de se nøglen vist i App-feltet + et tomt NwkKey-felt — og kan reprovisionere korrekt. Bevidst valg at lade dette være en bruger-handling fremfor automatisk data-flytning; sig til hvis I foretrækker en data-migration.Companion PR