Hmm no answer here…
Same issue here: stuck in boot loop, unable to activate. Ethernet as well as WiFi.
I’m a bit sad having to wait this long and then it’s not even possible to do the initial setup
I think the gateway gets the frequency configuration URLs, and using that one specific frequency configuration, through https://account.thethingsnetwork.org/api/v2/frequency-plans/ The contents might be the same, I’ve not checked.
Updated gateway status this morning: still cycling, best status is the following:
Gateway Information
Version Info
Hardware: v1
Bootloader: r1-7167873a (2017-06-02T13:48:18Z)
Firmware: v1.0.0-917719b9 (2017-06-26T17:59:33Z)
Network
Uptime: 29
Connected: true
Interface: WIFI
Wifi SSID: xxxx
Configuration
Activation locked: true
Config correct: true
Region: EU_863_870
Gateway Card: 868Mhz
Packet forwarding
Broker connection: false
Packets up: 0
Packets down: 0
Miscellaneous
External storage: false
Where can I find the list of pages/commands available from the gateway web server at http://things-gateway.local
? I know of
-
http://things-gateway.local/info
-> page as post above -
http://things-gateway.local/ssids.cgi
-> list of seen WiFi networks
A few I posted earlier, with emphasis on “Not quite useful”:
Update. Tried to activate the gateway for a wired Ethernet connection. It goes into a reboot loop again, but the led-patterns are different. It displays “connect to the internet”, and then “activate”. I can see the device on my home network. Then, the first two leds are on, no flashing. Then it goes into a reboot.
are these problems
- firmware
- hardware
- backend
- isp
- firewalls
related ?
What can I do here, change my WiFi access-point without any authorization?
I got this information reading the documentation published on the by The Things Network on their site, so if it’s I correct then they need to update it ? Only trying to use the information at hand to try and identify more info about this reboot issue and possibly root cause.
https://www.thethingsnetwork.org/wiki/Backend/Connect/Gateway
Thank @arjanvanb , I think this should be available on the FAQ page. When digging in an issue it is difficult to predict what will be useful as the bug is usually in a place that we expect to be clean
All well, but to my information, there are quite a few initial backers stuck with not usable TTN-gateways at this moment. Some information is becoming available in this thread. But it is mainly from backers, and without a clear identification of root cause and solutions yet. So, be prepared to answer questions from your initial backers as to how this problem is going to be taken up by The Things Network. I would like to see the problem being acknowledged by The Things Network, and a clear outline of the process that is going to be followed.
You are not touching your access point here, you are linking the gateway to the selected WiFi network.
I would say we don’t know exactly at present, if the firmware/hardware reboot is caused by a edge case created by an,issue with backend issue or environment (isp) more information is needed.
there are 160 gateways more active then 5 days ago, active, not activated, many of them are new TTN gateways, how many I don’t know.
trying to figure how many are working correctly and why are they working correctly, its not that every delivered gateway gives problems.
I am surprised that enclosure of the gateway that has some relatively high dissipation components (I measured up to 50°C on some surfaces while ambiant temperature is below 25°C) has no opening and no efficient radiation surfaces (no metal plate or other radiators). I don’t think that it is related to our issue but it it is surprising to me.
I drilled holes in my ZIGGO television decoder for that reason
Haven’t connected to my TTN-gateway via the serial port. On the home network gateway, it looks like the TTN-gateway is connected (wired or wireless). From the outside, and without proof, it could even be basic networking: like a failed DNS lookup, incorrect gateway address, or comparable. Do you think that can be checked?
There is a condition that forces our gateways to reset instead of continuing trying to connect.
Question to TTN: is there a way to know what is the source of the last reset when we restart ? Any log or trace or LED signature ?
yes i get that, the thing is that anyone on the local network can do this change …