V3 community to V3 Enterprise cloud and Devices will not Authenticate (downlink not working)

So recently added a few new gateways and devices to the V3 stack because of the V2 shutdown. everything worked as intended. Then I decided it was time to move to the enterprise version and migrated the devices from one account to the other. no issue ( none of these devices have ever been online x200 total) Next I deleted the gateway from the community addition and added it to my new cloud instance with success. ( yes I did update the Server address on the gateway to match the new server location) this was confirmed by the gateway connecting and showing online. the issue is after starting 5 devices up for the first time, I can see the join request come into the gateway but no Downlink acknowledgment is sent so the devices never authenticate… these devices and gateways with the same settings( apart from the server address ) worked perfectly on V2 and V3 community. now I’m getting this issue.

Other info

Mikrotik Ltap gateway.
Tried forcing scheduling and removing it
Tried making delays time longer and shorter

LNS and CUPS not being used as Ltap does not have these options yet.
I need to get this going ASAP, I have emailed support but awaiting a response…

SIde note… is it just me or does it feel like we are moving backward by having to configure stuff again via CLI and not everything via console.

Sorry but on the forum we only support the community network.

The only thing I can think of is airtime issues for the gateway if it needs to transmit too many replies in short order. (I think this is averaged over 1 hour in TTS)
For regular devices and gateways you should not change setting much. More changes usually means more issues.

With regards to CLI, last time I checked there was a console just like for the TTS(CE) available for enterprise instances as well.

BTW, you should not be seeing downlink acknowledgements but you should see join response packets. Have you checked there are no issues with duplicate nonces? Or a wrong version of LoRaWAN standard being used for the devices?

The CLI is the official one true source of control - many things it can do that the console is unlikely ever to …

isn’t congruent with

They may not be the same physical device, but if the EUI’s & Keys were used on TTS CE …

Which gateways hear the join request?

Hi @kersing Understood about the community addition only but I’m assuming is relevant for anyone moving from community to enterprise to know what they in for?..

As a test, I did disable the duty cycle limitation but made no difference. moved the devices back to community addition and it worked as before… so I’m not sure we are dealing with a version difference here?

Another question that I can’t find info on. if I have another gateway and device running on community. and my current setup on enterprise, both applications that were set up uses the same Join EUI for the devices will that cause issues?

With regards to the acknowledgment vs downlink packet confirmation please see below.
As far as I can see there is no attempt in sending the downlink

image

This is also confirmed to be the case on the actual gateway

image

Hi Descartes,

Not 100 % sure what you mean by “isn’t congruent” but I’m assuming you mean they can’t all be switched on at the same time, they are not. minutes between each one is activated and they all have randomized retry features for a total of 5 times over 12 hour period. This possibility as an issue is eliminated because using the same devices in the community works on the first transmission. within 15 minutes all 5 devices have joined and worked as intended. remove the devices and the gateway. add them to enterprise and nothing. restart the device to force rejoin. still nothing.

Where does the upper case d come from?

You said that the 5 devices were starting up for the first time but also said you were using the same settings (which could mean anything, including EUI’s).

You disabled the duty cycle limitation on what?

The version number is at the bottom right on the web console.

In theory, if the gateway is pointing to a private network server then the JoinEUI could be the same, in practise it may be affected by the Packet Forwarder.

You said “but no Downlink acknowledgment is sent” hence the query about downlinks - did you mean Join Accept?

What is the device - can you give it a totally new set of credentials so you can eliminate any issues with prior registration on CE?

That would be assuming they run into the same issues which isn’t a given.

Make sure the devices are only registered at one instance. Either community edition or cloud instance. Having them at both will cause issues.

What LoRaWAN version are your devices configured for?

Yeah, bit unlikely that a TTS CE user is going to run in to a “I moved my devices from TTS CE to er, TTS CE …” sort of problem.

And just incase the OP does post again, I’m allergic to the presumption we HAVE to help - the only ones that sort of HAVE to help are the support desk, assuming you pay for support …

@descartes Really? no one said you HAVE to reply… i asked a question didn’t complain that you didn’t reply. TR

Enterprise version is v3.13.2
Community Version is v3.13.2

Agreed they are only registered on one instance at a time. have loaded brand new devices onto the enterprise version first. no luck… move them to community and they work first transmission.
( I have 200 devices to load and get active ) so I can use new devices with new credentials to test the problem a few times.

I will need to confirm the LoRaWAN version used on the devices. dont have access to the engineers at the moment since im EST they are SAT time.

Thank you for the assistance, i will need to wait for support to wake up and get back to me since some people are getting sensitive over nothing.

If you use the same settings in CE and Cloud things should behave the same. Assuming your gateway polls your cloud instance for downlinks so TTS is able to schedule a downlink for the join reply.
Keep in mind moving your gateway between instances might trigger security measures in place to prevent people faking gateways they don’t own.