Dont suppose you have any other GW types running on the network?
In fact, I have a Multitech Multiconnect Conduit Gateway (Model MTCDT, Node ID: 00:08:00:4A:3C:F6) active on the same network. Is that relevant?
I unfortunately don’t administer that Gateway, so I can’t tell you for sure that it’s working or how it connects or anything like that. But I can tell you that an end device test succeeds, and that’s the only likely pathway for it to do so at the moment.
Ok - let us know which one (EUI and GW-ID) and we will keep an eye out for any connectivity…again asking @KrishnaIyerEaswaran2 Krishna if he can check back end for any action - or perhaps chime in with any suggestions…
Good - and you can confirm live/online right now? Do you know what PF is being used - UDP based, BasicStation, other? At least we know you can reach the LNS if that is live (port and protocol dependent ofcourse)…which leaves us tacking access to the 3rd party CUPS for initial configs…lets see how your colleague gets on overnight!
If the TTIG that worked had been stable then we knew likely connection from the local network to LNS would be ok - protocol dependent of course so not guaranteed… the new ones will need to connect to the 3rd party CUPS server to grab config info - which will include then pointing it to talk to the LNS - which is likely the current stumbling block I suspect. Lets wait and see what ‘colleague’ discovers from home network overnight. If still a prblem then I start to suspect if GW’s set as ‘claimable’ by/for TTN/TTI…
@descartes The new TTIGs never worked, neither while using my phone as a hotspot nor while using the cable-modem based Wi-Fi network. While trying to use my phone as a hotspot, I unplugged the Wi-Fi router to be sure there as no way it could be implicated.
When I initially registered the new units, the EUI’s I entered correctly took me through the TTIG process asking for the Wi-Fi password to claim the unit.
@Johan_Scheepers I have a bunch currently live with no (unknown) issues right now - ok on eu…, point is that unless they have successfully connected to the CUPS server to download initial configs they never will appear online in console and will continue to ‘blink’!
This is expected behaviour of the LBS protocol. Gateways must connect to a CUPS server since when they leave the factory, they don’t have an LNS configured.
@vicatcu: The other thing you can do is to do a reset on the gateway. Hold the reset button for 5 seconds and then setup the WiFi again. If you can try that and post the EUI, I can see if it contacted the boot CUPS server.
Today I deleted and reclaimed all three of these units, did a hardware reset on them and reconnected them to the same Wi-Fi network, and all of them were able to get to a solid green light. I don’t know what happened between the start of this thread and now, or if someone at TTN took notice of this thread and fixed something, or if a cosmic ray knocked something loose in my network or in my region of the internet backbone, but whatever it was that was thwarting me is no longer thwarting me. That’s great, but as an engineer, I find this sort of thing exceedingly unsatisfying. Hope everyone has a great rest of their week / month / year.
We are all TTN but yes, someone from TTI took notice, their post was directly above your own.
Me too, but happens so much I’ve stopped caring - these systems are so complex that whilst they have much in the way of fail over & redundancy, it only takes a glitch that comes with a TTL to poison the well for a few days.
That’s great to hear. I can vouch for the fact that no action was taken on the server.
Since the TTIG is currently a blackbox, it’s a bit difficult to debug. TTIGs have a little USB C debug chip (I forgot what the technical name is) which can be used to read serial logs without opening it.
I’ll check with the manufacturer if these can be made available via the resellers.