@fullstomp You are a lucky guy, I did not get more success today
@descartes Is that possible to get a feedback like “someone is working on understanding the problem”, There is no emergency to migrate but refreshing post and retrying connection twice on daily basis is a bit disappointing if no one else look at it.
@rharte I’m not really understanding why pinging me… basically I’m trying to migrate to explain the procedure to human
1 Like
I have a vested interest in this so I am working on understanding the challenges of migration - I have all sorts of device formats, both ones I’ve designed and other manufacturers devices that my clients have.
I know, as a moderator that scans the vast majority of posts, that others are working on this.
I know, as a moderator, that TTI are watching but they can’t pull changes out the bag and need to see the scale of the problems to be able to come up with a scheme.
As I keep saying, it’s only been a fortnight, we need to pool resources to work methodically and not come to any conclusions too early.
I have some more tests scheduled for this weekend - when the emails aren’t flowing and the phone doesn’t ring - so I will be re-running my migration tests again then.
1 Like
There were some Packet Broker issues that we resolved yesterday, indeed causing things to delay so badly that the join-accept delays were not being made.
Currently checking offline with @disk91 to see what the issue is. We have tried to replicate but we see consistently successful joins of V3 devices via V2 gateways.
This morning, after upgrading my Laird gateway firmware, the device get connected. I don’t think it is related to the firmware directly (I see no reason as the protocol is the same). But I had to redeclare the gateway in the TTN backend, even in v2. The gateway id changed from laird-disk91-1 to eui-c0ee40… It is possible the ttn servers have also changed (now it is router.eu.thethings.network)
The laird FW version now is Laird Linux gatwick-laird-93.8.5.21 it was 93.7.x previously.
That said ; it means V3 devices could not be able to join V2 infrastructure currently running correctly.
I may have 2 other gateways with same configuration as the one migrated. I’ll make some join try on them to see if we can reproduce. (A bit more complicated to me as these gateways are not at home but deployed)
1 Like
interesting - my first V3 gateway was/is a RAK833 on a Pi3 - it was very variable until I compiled the packet forwarder from the latest version and since then it’s been spot on.
Maybe there is something that V2 could tolerate that’s not acceptable in V3. Another thing to investigate!
1 Like
The other difference is:
- current version uses Semtech UDP (legacy)
- previous version seemed to use the old TTN protocol (before basic station, don’t know how to name it)
Could be the reason why ?!?
Yes, that’s it. We don’t have forwarding to Packet Broker with the long discontinued TTN packet forwarder using the gRPC protocol. We’ll add that to the instructions, thanks, issue found!
1 Like
@johan can you please confirm that my kickstater gateway data is not forwarded from V2 to V3? And as aresult if that, joins will fail?
So basically our kickstarter gateways won’t be able to be connected in V3 anymore ? Is there a firwmare upgrade to support it ?
You are jumping to conclusions. There is a manual on how to connect Kickstarter gateways to V3 so it is extremely unlikely it can’t be connected.
Ok, cool ! thank you for sharing, I’ll upgrade my gateway soon … (… I have a lot to upgrade and all different !! )
Another question to make sure:
Does ttnv3 accepts Semtech Legacy protocol or just Basic Station ?
No, thats not what I said. I have successfully migrated a Kickstarter gateway to V3
Perhaps spend 5 minutes on the documentation site?
The answer is V3 does support the Semtech UDP protocol as well as BasicStation and ttn-gateway-connector protocol. (The last protocol being used by the Kickstarter gateway and by gateways running mp-forwarder.)
1 Like
Can’t confirm, those gateways are also connected to endpoints that are offloading to Packet Broker.
And indeed, you can connect them directly to V3 too.
1 Like
Thank you for your answer
Where did you get the information that mp-forwarder is supported in the documentation ? I was not able to find it and this question is basically the reason of that topic.
https://thethingsindustries.com/docs/gateways/
Found by going to:
Home | The Things Stack for LoRaWAN and typing “packet”
But could have clicked on Gateway icon and, boom, there it is left hand column, second square down.
Maybe worth exploring the micro-site.
Haven’t looked for it in the documentation. Happen to have a special interest in mp-forwarder (being the author does that 
) and because of that I already tested with a private instance of the stack before V3 was released. Have one of my gateways running it on the public V3 now. (The advantage of having 5 gateways on site, you can migrate one without sacrificing applications still on V2)
If you migrate to public V3 you’ll need to specify port 1881 for any connection using server type TTN. Do not add ‘@TTN’ to the serv_gw_id, just use the name. And you will have to create an API key as listed here.
2 Likes
I did not know I was lazzy
By the way, I’ve found that page earlier: that’s clear for the SEMTECH UDP legacy packet forwarder. But I did not find anything about mp-forwader, so here was my question
The Things Kickstarter Gateway, is a gateway, not a protocol, apparently even if supported it is not working with Laird, so what can I conclude ?
But don’t use the Pi install script - it’s a bit rogue - do the commands by hand - works fine then. 
Opps, my bad. Apologies.