Hi All,
i tried to import active OTAA Sessions from a LoraWan Server running 1.0.2.
Unfortunatly i allways receive an MIC error.
I used the API to transfere Device Adress, AppKey, AppSKey, NwSKey and disabled the Frame Counter Check.
First i created the device via API
The i created device keys providing the AppKey as nwkKey
than activated it using the Session Keys.
Do you know what else could be wrong or missing. I feel like i am only one step away 
Disabling the frame counter check was a mistake; you should have copied knowledge of the current uplink and downlink frame counters.
Trying to disable it causes two problems (beyond breaking replay attack security): First, if the frame count has already rolled over the 16 bit boundary, then the MIC which is calculated from the true 32-bit value will be different than the one obtained when the evident 16-bit frame count is assumed to have zeros in the upper 32 bits.
Next, telling the network to ignore uplink frame counts in violation of the spec doesn’t mean that the node is going to start ignoring downlink ones in violation of the spec; since the node knows the last downlink frame count it received, it should reject any traffic coming from a network server that’s starting the downlink count over from 0.
Hi @cstratton ,
thank you for your help. i disabled the frame counter check to make debugging easier.
I even get a MIC error, when i use a new and i import the fncount =1.
Is there any other thing i might be missing.
Now i build a test setup with a dragino LHT-65 FW 1.8 and i have the same Problem.
It seems like it is not possible to migrate OTAA Sessions.
i try to copy this session:
an i allways get an MIC error:
You need to configure AppKey in The web-interface KEYS(OTAA) tab.
I did this via gui and via API. Both don’t work
@sagarpatel and @cstratton
do you habe any other idea where i can look. I try to copy a active session from a lultitech conduit.
This is the Session:
This is one Packet
This is the result if i try to decode it manually. Even here the DEVaddress and the MIC is wrong.
Is it possible, that the LoraServer from the Multitech and the one from Chirpstack are calculating MICs differently.
Is there anyone who has sucessfully imported sessions from another LoraServer into Chirpstack.
Any Help would be highly aprecciated since i need to migrate ~600 Sensors
I found the Solution, which in my optinion is a BUG.
In Chirpstack the MIC for LoraWan 1.0.2 seems to be calculated using
fNwkSIntKey or
nwkSIntKey
instead of the
nwkSEncKey
So in all three fields you have to enter the NwkSkey. MAybe it helps somebody else.
Then it’s apparently wrong in the node’s transmission
No, the LoRaWAN spec dictates the calculation, there can be only one correct method.
