Can I register an ABP device that has fixed DevAddr, NwkSKey and AppSKey?

I’d like to connect an Ideetron keyfob dongle to TTN

This is not user-configurable and each one has a 32-bit factory-set DevAddr EUI, while the ABP NwkSKey and AppSKey are shared for all devices:

Frequency: 868.100 MHz
DR: 125 kHz
devaddr: see sticker
nwkskey: 2B7E151628AED2A6ABF7158809CF4F3C
appskey: 2B7E151628AED2A6ABF7158809CF4F3C

I tried to set this up as an ABP device but there appears to be no facility for entering the EUI.

Can a device like this work with TTN?

You need to define the device as an OTAA-device.

Thx @vannut. But this is a device with everything fixed incl the app key. So if I set it up an OTAA (which I also tried) the app key won’t match. It does not activate.

This used to be possible in early versions, but is not supported in LoRaWAN; see below.

As far as I know, the command line ttnctl tool still allows for that. On one line:

ttnctl devices register personalized <your DevAddr> 2B7E151628AED2A6ABF7158809CF4F3C 2B7E151628AED2A6ABF7158809CF4F3C --relax-fcnt

However, these are the Semtech default demo keys, and are insecure as everyone knows them. Also TTN does not truly support those keys:

The default keys are not supported in the new backend because they are not secure.


We will not actively reject keys, but messages might not be delivered if someone else registers the same device address with the same keys.


3 posts were split to a new topic: Download of command line “ttnctl” shows file is corrupt

thx @arjanvanb

I have registered it this way. As soon as I can get near a gateway I’ll see if it activates.

It does not activate. When I look at the setup it has fewer parameters populated. Only DevEUI, AppEUI and AppKey. Other devices seem to have Network Session Key and App Session Key. Can these be added (e.g. via cli)?

Where do you see that info? If you’re seeing dots, you need to click the “eye” icon to show the secret details. (But that’s also the case for other devices.)

In the ttnctl devices register personalized I showed above, the values 2B7E151628AED2A6ABF7158809CF4F3C are the (demo) network and application session keys:

Usage: ttnctl devices register personalized [DevAddr] [NwkSKey] [AppSKey]

Maybe you can use ttnctl devices info [DevAddr|DevEUI] to see what’s stored, just in case the GUI has some bug.

Thx @arjanvanb. It worked better with all 3 parameters as you indicated. I can now see all parameters on the GUI. Now back to testing again.

Hmm, not sure what you tried before, but yes, you need all 3 parameters. Also, you might want to add the --relax-fcnt flag like I showed in my first post.

(Beware you might not see the horizontal scrollbars in my first post?)

Thx @arjanvanb . I connected this node : to TTN using your instructions:

ttnctl devices register personalized your DevAddr 2B7E151628AED2A6ABF7158809CF4F3C 2B7E151628AED2A6ABF7158809CF4F3C --relax-fcnt

Since two weeks ttnctl.exe does not seem to work anymore. I can use the web dashboard to modify existing ABP nodes but need the ttncl.exe to generate ABP nodes with fixed DevEUI etc.

D:\ttn>ttnctl user login Password: INFO Visit to register or to retrieve your account credentials. FATAL Failed to login error=Grant type is not available for the client My password which always worked before is not accepted any longer.

We recently launched version 2.0.0 of our backend, which is no longer compatible with v1-staging. You can configure your v1-staging ttnctl with ``–ttn-account-server` to delete your old devices from v1-staging and move them to our v2 backend.

See Launching Production Environment for more information.

1 Like

Pfoe that did the trick. Thanks!.

So we should start migrating. How long will the “old” staging environment be alive?


The Roadmap says Q1 2017.

As an aside: network providers (such as TTN) are required to actively block devices that always send on SF11 or SF12, to keep their LoRa Alliance NetID: Devices with fixed hardcoded data rates of SF12 or SF11 must not be allowed to join the network.


It’s not possible to register just any DevAdr, as it includes a network identifier:

The most significant 7 bits are used as network identifier (NwkID) to separate addresses of territorially overlapping networks of different network operators and to remedy roaming issues. The least significant 25 bits, the network address (NwkAddr) of the end-device, can be arbitrarily assigned by the network manager.


The seven LSB of the NetID are called NwkID and match the seven MSB of the short address of an end-device as described before.

The documentation on Addressing and Activation explains some more:

The Things Network Foundation has received a 7-bit device address prefix from the LoRa Alliance. This means that all TTN device addresses will start with 0x26 or 0x27 (although addresses that start with these might also belong to other networks with the same prefix).

(TTN currently uses a NetID of 0x000013, hence its NwkID is the 7 bits binary %0010011. As hexadecimal 0x26 is binary %00100110, and 0x27 is %00100111, both indeed start with the 7 bits NwkID.)

Also, the TTN-assigned DevAddr uses some more encoding for internal routing. From the same documentation:

Within TTN, we assign device address prefixes to “regions” (for example, device addresses in the eu region start with 0x2601). Within a region, the NetworkServer is responsible for assigning device addresses. We are using prefixes here too for different device classes (for example, ABP devices in the eu region start with 0x26011) or to shard devices over different servers.

(This indeed yields less than 12 bits within a region and class to generate a DevAddr, yielding only 4,096 unique values within such region and class. This is not a problem as a DevAddr is not unique.)

@htdvisser wrote in Slack, about just copying some existing DevAdr into TTN Console:

No, that won’t be possible in the public network

We route data based on the NetID that was assigned to us by the LoRa Alliance

Devices with a DevAddr that does not match our NetID, are (according to the LoRaWAN spec) part of another network

If a manufacturer puts fixed DevAddr/NwkSKey/AppSKey in a device without giving the customer the ability to change those, they either don’t know what they’re doing or they don’t really care about the customer or they try to create some kind of lock-in to their own network.

And if if the NwkSKey/AppSKey is 2B7E151628AED2A6ABF7158809CF4F3C I would think twice before buying the device.

And about the test NetID 01/02:

We don’t issue DevAddresses for 00 / 01 but it is possible to “force-register” a device with such address (not in the console, only with ttnctl)

For such devices, we can still route data

But uplink for anything else than 00 / 01 / 26 / 27 will just be dropped before it’s even considered by the backend

Or routed to a roaming partner when roaming is added to LoRaWAN and supported by us

1 Like

Thanks for this info.
Is there somewhere a list of assignments NetID <-> LoRaWAN Network Provider?

Thank you for the helpful information. I have devices whose DevAddresses begin with 00. How can I force-register these devices over the ttnctl?

Thank you very much for your help!

ttnctl devices set my-device-id --override --dev-addr 00000000 --nwk-s-key 00000000000000000000000000000000 --app-s-key 00000000000000000000000000000000