Interesting. When, from Boston, I try a tracert to that same address I am also getting just requests timed out after getting to ae6.0.db3-96c-3a.ntwk.msn.net
Don’t have any gateways yet, expecting delivery tomorrow.
Interesting. When, from Boston, I try a tracert to that same address I am also getting just requests timed out after getting to ae6.0.db3-96c-3a.ntwk.msn.net
Don’t have any gateways yet, expecting delivery tomorrow.
you cant use ping and ICMP will more than likely be blocked by NLBs
https://www.thethingsnetwork.org/wiki/Backend/Connect/Gateway
When you connected the gateway using a wire, the access point is still visible. Did not try to abuse it yet.
Cheers,
Rene Klootwijk
port closed: 52.169.76.203:1700
Peeking into my serial log, I think my gateway connects just fine, and gets configuration data from the internet. Also, I’ve tried both WiFi and ethernet, with two different Dutch providers. Mine does not even get to trying to connect to the bridge; it reboots after failing to apply the frequency configuration it fetched from the internet. (If that content was valid; we cannot tell if it’s the same content or format that a browser would show, and somehow it seems to report a weird size in HTTP: Got 1232 bytes
, but that size is the same for gateways without problems.)
A ping bridge.eu.thethings.network
from the gateway itself resolves to 52.169.76.203, but gets not reply, like you already explained yourself above:
ping bridge.eu.thethings.network
Ping: resolving host: bridge.eu.thethings.network
Ping: request sent to: bridge.eu.thethings.network [52.169.76.203]
Ping: done. Sent 4 requests, received 0 replies.
Same for account.thethingsnetwork.org
. All this does not look alarming to me, and I don’t think we can issue other useful commands from the gateway to investigate.
The TTN gateway is not using UDP or port 1700.
Just curious, did someone made a thermal picture of the gateway pcb while operating for some time?
Configuring Your Gateway
In the local_conf.json of the packet forwarder, update the fields server_address as follows:
“gateway_conf”: {
…
“servers”: [{
“server_address”: “”,
“serv_port_up”: 1700,
“serv_port_down”: 1700,
“serv_enabled”: true,
…
}]
}
according to ttn wiki
Here you can find some:
Sure, for a non-TTN gateway. Don’t argue with The Guy Who Knows All About Packet Forwarders:
I’m think what we need is a gateway emulator that way we can simulate the process that the gateway uses to rule out environmental issues ? then focus on the protocol/firmware/hardware diagnostic outside in approach
Looks like the problem I am having is that at least once a day the gateway has trouble connecting to the local wifi, so then it just sits there blinking the second led quickly until it is power cycled. Is there not some automatic retry when the wifi connection times out? Or what is the best way to manage this, since I don’t want to have to put the gateway on a timer and have it power cycle once a day or something equally absurd.
After a succesfull activation of the ttn gateway via wifi it dorps the wifi link to ap after a few hours. I have to reactivate the gateway due to configuration lost. Anyone?
cheers Hans
Just posted the same problem, also hoping for a solution.
Looks like after failure to connect via wifi there are no subsequent retries, so maybe this can be fixed in the next firmware release (or maybe it already has been since I am using firmware from July 2017).
But yes, this is rather inconvenient at the moment.
It seems the TTN gateway is rebooting every 24 hours, even with automatic updates off, why??
I have a lorank8 gateway up for almost a year without any interruptions.
Very interesting, many thanks !
I’m going to attempt to deploy a private network following https://www.thethingsnetwork.org/article/deploying-a-private-routing-environment-with-docker-compose in hope of helping identify these root cause of the reboots and rule out any environmental issues
Q: has anyone checked/verified the power supply is providing and capable of providing the correct voltage/amp when the gateway is running? could the rebooting be a simple low quality power supply not able to provide a stable rate of power ?
I see the same behaviour, every 24 hours a reboot.
FYI, I reached out to @rish_ttn via email and got a reply, I’m hoping that the team at TTN take onboard the observations and officially do a communication about the continual rebooting and or other issues they are seeing with regards the gateway etc… SOON
I have made a video of what’s happening when the gateway starts until something happens on the LoRa card tha eventually triggers the reload. Hopefully the LED pattern (along with the serial dump that other have published) will be able to help the TTN team to address this issue?