So I am upgrading a device to V3, and I can refresh it so just to create a new application in the NAM1 V3 environment and a new ABP device. I followed the migration instruction here with the exception of that I simply create a new DevAddr and NwkSKey along with the new V3 application key but with the server at nam1.cloud.thethings.network. Basically, as if I was never on v2 and simply creating a new ABP device in a new app. I grab the NWKSKEY, APPSKEY, and DEVADDR value and program my device with them. I double, triple, and gradual check that my keys are correct. However, when ever this device transmits, my V2 gateway received the signals, but generates a “router ttn-router-us-west drop … reason:no brokers” error (as viewed my the V2 console for my gateway).
What would be causing this? I’ve read other posts that indicate the NWKSKEY, etc, could be wrong, but I assure you the device is programmed with what was generated in the V3 application console on NAM1.
If you’re willing to burn a set of secrets, you can take the raw packet as reported by your gateway and drop it into the online LoRaWan packet decoder and see if it validates against that NwkSKey or not.
I’d been under the impression that V2->V3 forwarding was not implemented or implementable for ABP; there’s now a claim that this is mistaken and it should work, but I still have to wonder.
What’s the actual device address you are using? That’s not private, and something more knowledgeable folks could figure out if validly belongs to one network or the other - or neither.
@cslorabox Thanks! I am willing to burn a set a secrets (as I can generate new ones once I solve this), but I don’t really know of this “online LoRaWan packet decoder”, but I did find something fitting the description online. Just to make sure it’s the same thing, do you mean this?
If ABP is not implemented for V2->V3, that implies I need to upgrade my gateway to make the work?
Dear kamprath, i’m having the same issue, DevAdd it is 260BE86E ( generated on V3 console… though it should be different range…) , i’ve check the packet with https://lorawan-packet-decoder and everything it is ok, it is just like the DevAddr generated on V3 console it is really a V2
Please read this message from Hylke regarding the subject. Specifically
When creating new ABP devices on V3, you can request a DevAddr from the Network Server, and Packet Broker routing (at least of uplinks) will work fine.
No, that means it won’t be handled in the V2 cluster. Forwarding to the packet broker which delivers it to V3 is a separate process that is not listed in the V2 progress. (Yes, the naming of broker and packet broker may be confusing)
Ok, understand this is something that V2 gateway traffic view can’t display, but as long as device is configured in V3, and V2 to V3 traffic should be forwaded, still don’t know the reason why my V3 console doesn’t show any traffic from the node
Please read this message from Hylke regarding the subject. Specifically
When creating new ABP devices on V3, you can request a DevAddr from the Network Server, and Packet Broker routing (at least of uplinks) will work fine.
As indicated above, I did, and my device address is 0x260CAD99, which per the other article you cite above clearly indicates is a v3 device in North America. Which makes sense since I set it up on the NAM1 v3 cluster.
I guess under what circumstances will following the instructions for setting up an ABP device on v3 not actually work? Is there some other bit of information that is needed here?
And to be clear, when I reprogram the device back to it’s original v2 device address and keys, it works fine. My v2 gateway is clearly working fine as it forwards the packets when the device is v2, and it receives the radio signals but can’t find any brokers when the device is V3. One thing I will note is that everyone who claims it is working for them seem to be on the Europe server (v3). Is that an important details here? Is the NAM1 server, or the ttn-router-us-west router my v2 gateway connects to, ready to go for this?
Why I haven’t migrated the gateway to v3 is because all the instructions say to do that last and migrate your devices first. I’m just following instructions here.
Have you validated that the raw packet transmitted with the V3 device address validates with the keys you entered in V3?
Yes, I grabbed the raw encrypted bytes from my v3 ABP device that were received by my v2 gateway. They decode with the v3 app’s NwkSKey and AppSKey, and I find the payload as I would expect it. The uplink counter is what I would expect it to be (to be clear, I’ve tried resetting and not resetting the uplink counter on my device). The gateway console in v2 TTN reports that the payload failed with no brokers, and I never see any live data in the application’s v3 console.
As always, let me start by saying that you should not use ABP unless you have a very good reason; OTAA is always preferred. If you do use ABP, you should not just randomly pick a DevAddr; instead you should request one from the Network Server, and use that.
The “router ttn-router-us-west drop … reason:no brokers” indeed doesn’t mean that traffic isn’t forwarded to Packet Broker. I’ll see if we can do something to somehow make this a bit more clear.
All ttn-router-* and *.cloud.thethings.network are connected to Packet Broker. If any cluster receives traffic for DevAddr block 260C0000/16 (see also the list of blocks in this forum comment) , that traffic should end up in nam1.cloud.thethings.network.
As always, let me start by saying that you should not use ABP unless you have a very good reason; OTAA is always preferred. If you do use ABP, you should not just randomly pick a DevAddr; instead you should request one from the Network Server, and use that.
Yes, I see that message everywhere in the V3 messages. But I have also seen “ABP is supported”.
And Yes, I had the NAM1 server generate the V3 DevAddr I mentioned earlier. I did not randomly make it up myself. In fact, I have had the NAM1 server make 3 different DevAddr values and all 3 have produced the same results.
The “router ttn-router-us-west drop … reason:no brokers” indeed doesn’t mean that traffic isn’t forwarded to Packet Broker. I’ll see if we can do something to somehow make this a bit more clear.
OK … I only emphasized the “no brokers” message because it seemed like the error. Ultimately, the real problem is no data from my V3 device ever shows up in the V3 application’s live data console.
All ttn-router-* and *.cloud.thethings.network are connected to Packet Broker. If any cluster receives traffic for DevAddr block 260C0000/16 (see also the list of blocks in this forum comment) , that traffic should end up in nam1.cloud.thethings.network.
Again, this does does not appear to be happening. I don’t know how to diagnosis it any further, hence my request for help.