Enabling “Beta Updates” in TTN Console does not show anything different than my earlier log. In other words: I don’t see it trying to download the firmware, maybe as it never successfully completed Step 4 of its initial activation.
Also, erasing the serial flash (holding down the “mode” button while powering up) and then using ethernet rather than WiFi in Step 3 of https://activate.thethingsnetwork.org, makes no difference: I still see it fetching some frequency configuration from the internet, soon followed by LORA: Configuration failed, retry (sometimes two times) and then rebooting.
Unlike I thought earlier, the reboot reason is not only Reboot reason: 0x13 but often shows Reboot reason: 0x53. I don’t know which one is shown why.
In the earlier and today’s log I noticed HTTP: Got 1232 bytes (I assume decimal?) for both WiFi and ethernet in:
FREQ: APP_URL_Buffer: https://account.thethingsnetwork.org/api/v2/frequency-plans/EU_863_870
HTTP: Starting connection
HTTPS: Connection Opened: Starting TLS Negotiation
HTTP: Wait for TLS Connect
HTTP: TLS Connection Opened: Starting Clear Text Communication
HTTP: Got 1232 bytes
…but https://account.thethingsnetwork.org/api/v2/frequency-plans/EU_863_870 shows Content-Length: 3309 (decimal, excluding any HTTP headers). Could that difference in size indicate some problem?
Of course, maybe those lines in the log are very much unrelated. Or maybe the gateway gets it in some gzip’d transfer encoding, while my Chrome does not.
…apparently being the following, which I don’t know how to use:
------- Supported command groups ------
*** tcpip: stack commands ***
*** wifi: Wi-Fi commands ***
---------- Built in commands ----------
*** reset: Reset host ***
*** q: quit command processor ***
*** help: help ***
Did you find something more?
And some asides:
-
For WiFi I use an XS4ALL FRITZ!Box modem. This supports IPv6 but the gateway does not seem to use that, or prefers IPv4. The gateway’s information page can be reached at both http://things-gateway/info and http://things-gateway.local/info
-
For ethernet, I use some Ziggo/UPC Technicolor modem, IPv4 only. Its DNS needs the
.localsuffix; the gateway can only be reached at http://things-gateway.local/info -
When using ethernet, it seems the activation JavaScript relies on
things-gateway.localto resolve. -
The http://things-gateway.local/info page will keep refreshing its details depending on its internal state. Like: “Config correct” might first show “false” but “true” later, “Region” might be empty first but become “EU_863_870”, and “Gateway Card” might change from “ND” (not detected?) to “868Mhz”.
-
When trying to use the Ziggo ethernet while the XS4ALL WiFi was still configured, the ethernet’s DHCP would just be too slow for the gateway to get a lease, so it would choose WiFi instead.
-
Not quite useful, but some URLs: http://things-gateway.local, http://things-gateway.local/info, http://things-gateway.local/id.cgi, http://things-gateway.local/status.cgi, http://things-gateway.local/settings.cgi, http://things-gateway.local/ssids.cgi
-
I am using PlatformIO on a Mac to append the serial output to a file, while prepending a timestamp to each line (and adding a date to the name of the log file). Like:
LOG="ttn-gateway-`date +'%Y%m%d-%H%M%S'`.log"; pio serialports monitor --raw -b 115200 | while read l; do echo "[`date +'%F %T'`] $l" | tee -a $LOG; done -
I am using a Raspberry Pi to save the serial output to a file, while prepending a timestamp to each line.