LNS migration, devices no longer receiving downlinks

ChirpStack (v4)
1

I have a kind of odd edge case I am trying to work though. I am attempting to migrate a number of devices from a 3rd party LNS server into Chirpstack. I have the API calls worked out to collect the all the device data (DevEUI, JoinEUI, App key, and activation keys) and insert them into Chirpstack. And after running the process I start receiving packets from the device in Chirpstack as expected.

The issue is that after doing this migration the devices stop receiving (or respecting) the down links that are being sent by Chirpstack. So over time the device’s data rate falls to DR0 because it is not processing the ADR response Chirpstack is sending and begins broadcasting on 64 channels instead of the 8 channels my US915 gateway listens on (I have a 64 channel gateway I have used to confirm it is broadcasting on all channels).

My initial though was the downlink frame-counter I was getting from the other LNS was incorrect so the device was rejecting the packets thinking it was a replay attack. So as part of the migration I tried adding 10, 100, & 1000 to the downlink frame-counter to see if the device would accept the new count and process the downlink. Sadly no luck there. I have tested this on Chirpstack 4.10 and 4.14.

I saw @bconway post here about doing similar. And I’m doing exactly what is explained in that post. Just curious if anyone else has ever seen this issue before, and may know what I am missing. Sadly I do not have access to any dev logs from the device as the manufacturer is treating that as proprietary.

2

Disregard this as the device I am currently working with is cursed. I pulled a different LoRa device from a friend and did the exact same migration process with it and everything worked fine.
I’m going to have to get with the manufacturer of that original device and report a firmware bug of some sort.

3

If the FCntDown in the DownLink sent from the LNS to the device is equal or lower than the stored in the device, then the device will disregard that DownLink.
Another reason can be changed reception parameters RX1DROffset and RX2DataRate by the previous LNS.

4

I had tested those settings, and I made sure the FCntDown values were greater than the value from the previous LNS.
For some reason on this particular firmware version on the device it would not migrate properly if the ‘frame counter validation’ flag was set to true during the join process. I even tried migrating it between two Chirpstack instances with the same settings and it had the same issue as long as that frame counter validation was enabled, so I’m at a loss as to what black magic they have in the firmware but it is not something I can resolve for them.