well the traffic at V2 gateway says “reason:no broker” i didn’t meant it doesn’t try to forward.
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
Two things to try:
Provision the device on v2 to check it’s working as expected.
Setup a gateway on v3 with the device on v3.
FWIW, I have a v3 ABP device running since mid-Jan that gets forwarded by an old v2 gateway. So it does work.
What brand and model of gateway are you using and what software & protocol is used to connect it to V2?
this is The Things Indoor Gateway. connected to ttn-router-eu, and with automatic updates selected
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?
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.
I am not aware of any circumstances where it is not supposed to work.
Execellent question, @htdvisser I would expect nam1 gets packet broker traffic for the us clusters in V2, correct?
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.networkare connected to Packet Broker. If any cluster receives traffic for DevAddr block260C0000/16(see also the list of blocks in this forum comment) , that traffic should end up innam1.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.
I’d really appreciate some help here 
I’m not technically inept, but needing to navigate random forum posts and github PR comments to even know what is the relevant factoid to add here to get meaningful help is frustrating.
BTW, one factoid that hasn’t been asked of me yet and I don’t really know if it is relevant is that my gateway is a Laird RF191. Could that be a factor here?
What packet forwarder have configured on that gateway? If not the UDP based one you need to switch to it, the old TTN packet forwarder Laird shipped many moons ago is not supported and packets received by it will not be forwarded to V3.
What packet forwarder have configured on that gateway? If not the UDP based one you need to switch to it, the old TTN packet forwarder Laird shipped many moons ago is not supported and packets received by it will not be forwarded to V3.
I am using the “TTN Forwarder”. That’s actually all I know because the administrative UI doesn’t tell me if it is UDP or not. There is configuration presets for “The Things Network - US” and “The Things Network Legacy - US”. I am using the "The Things Network - US, maybe the other one is the one you are referring to as not supported? Anyway, the best I can tell from perusing the Laird site is that I have the latest firmware installed on my gateway.
That is the old obsolete software. Please switch to the Semtech forwarder.
Please switch to the Semtech forwarder.
Great! Do you know or know where I can find out what to set for the “Network Server Address”, “Port Up”, and “Port Down” setting for the Semtech forwarder?
EDIT: I did find this documentation on setting up a “Basics Station” on TTN at Laird’s website. Is this what I need to do? If so, it seems to imply do not in fact have the latest firmware.
Do not upgrade your firmware before switching to Semtech protocol. If you do you’ll need to reset to default settings.
The required information should be in the TTN console, ports are 1700 but site address depends on your location. You will probably need to register a new gateway in V2 as Semtech protocol is EUI based (legacy it’s called in V2).
OK, I have switched my Laird RF191 gateway to using the Semtech Forwarder, and used router.us.thethings.network as the Network Server Address, my v3 ABP device can now send uplinks to my v3 app. Thanks!
I now note a new problem. I cannot send downlinks to the devices anymore. What areas should I be investigating to solve this?
Isn’t the v3 address for the North America cluster for gateways nam1.cloud.thethings.network??
As the packet router will forward packets from v2 to v3 you’ve probably got away with the v2 address. However it can’t forward downlinks from v3 to v2 …