Single Channel Gateway shows "not connected"

Where do I find a list of the changes that were implemented by TTN 5 days ago?

I have two Raspberry PI based Single Packet forwarders that were both running reliably and both stopped being seen by the TTN Network. These gateways are 15km apart and stopped being seen within one minute of each other. Neither status messages or data from their nodes are being received on TTN.

eui-b827ebffff5efda5 was last seen at 3/17/2017 06:24:40
eui-b827ebffffbebbd8 was last seen at 3/17/2017 06:24:36

I can see via diagnostics on the gateways and nodes that they all still working correctly. Something has obviously changed on the TTN back-end.

Any pointers?

1 Like

What router address are you using ?

I quote Slack:

htdvisser [11:18 AM]
And regarding the online/offline, we indeed stopped showing gateways as online if they can’t do downlink

htdvisser [11:30 AM]
We’re becoming more mature and want to deliver good and predictable quality. If downlink messages “disappear” because a gateway can’t handle them properly, this gateway does not belong in a “production” environment

Good point. I am in the US. The address I am using is 13.66.213.36 which is the IP address resolved from the DNS lookup of router.us.thethings.network

However a ping of this address fails:

$ ping router.us.thethings.network
PING bridge.us-west.thethings.network (13.66.213.36): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
^C
— bridge.us-west.thethings.network ping statistics —
6 packets transmitted, 0 packets received, 100.0% packet loss

If it was cosmetic and only showed the gateway offline then I should still see the data.

The ping does not means anything: AFAIK, TTN is hosted on Azure and the Azure Load Balancer does not respond to ICMP requests :wink:

Thanks, that makes sense.

I also have a single channel gatway that stopped working today.
Initially I used the ip behind dns “router.eu.thethings.network”, but a few weeks ago that stopped for me.
After some reading here at the forum I ended up with 40.114.249.243 which as been working until yesterday.
Back again with “52.169.76.203” but not picking up from the gateway console in TTN.

Hi all,

I can confirm, two ‘old-type’ gateways using ‘router.eu.thethings.network’ are also reported down by the TTN console. I think we did not change and/or break anything.

In the console both are reported as not connected with a ‘NOC connection time-out’ error see screen dump.

Logging on gateways seems fine with a PUSH /PULL ACK received see:

Mar 23 22:00:55 gw1 ttn-gateway[715]: JSON up: {"stat":{"time":"2017-03-23 20:59:55 GMT","rxnb":1,"rxok":1,"rxfw":1,"ackr":100.0,"dwnb":0,"txnb":0}}
Mar 23 22:00:55 gw1 ttn-gateway[715]: INFO: [up] PUSH_ACK received in 47 ms
Mar 23 22:00:55 gw1 ttn-gateway[715]: INFO: [down] PULL_ACK received in 40 ms
Mar 23 22:00:55 gw1 ttn-gateway[715]: INFO: Disabling GPS mode for concentrator's counter...
Mar 23 22:00:55 gw1 ttn-gateway[715]: INFO: host/sx1301 time offset=(1490299095s:858225µs) - drift=-43µs
Mar 23 22:00:55 gw1 ttn-gateway[715]: INFO: Enabling GPS mode for concentrator's counter.
Mar 23 22:00:55 gw1 ttn-gateway[715]: ##### 2017-03-23 21:00:25 GMT #####

Hope this helps the ‘back-end’ people. (if not let me know)

Kinds regards,

Paul.

Same symptoms here – DIY gateway with an iC880A and Orange Pi zero, it works intermittently, but mostly what @paulboot says.

eui-024296fffe0d4641 currently shows as offline on the console but log looks like packets are moving both ways.

What does “downlink capability” mean?
Is it sufficient to have a gateway with the “full” software stack and multi-channel capabilities (vs. experimental single-channel gateway)

or

is it just an issue that the gateway cannot be connected from TTN over UDP port 1700 ?

1 Like

Downlink is the capability to send data from TTN back-end to a node. It requires the gateway to connect to port 1700, accept downlink data and send the data with the parameters (frequency and datarate) specified by the TTN back-end.

Multi-channel gateways with a packet forwarder based on the Semtech packet forwarder (which include at least basic-pkt-fwd, gps-pkt-fwd, poly-pkt-fwd and mp-pkt-fwd) with the right configurations meet this requirement. Other software might be suitable as well, however the single channel gateway with uplink only software (the default used for many single channel gateways) does not meet the requirements.

It requires the node to connect to port 1700

I don’t think the “node connects to port 1700”, as the node connects to the gateway using LoRaWAN protocol ant not TCP/IP.

I think you mean the TTN backend-end connects to the gateway via UDP port 1700, which then forwards the downlink data to the node as soon it connects to the gateway (LoRaWAN) the next time.

You are right, I corrected my message.

Things seem to be fixed. All gateways are online again and data is flowing again.

The TTN backend move from staging software/servers to production servers required us to recreate our Lora devices in the console which BTW is excellent!

Also the updated TTN Arduino libraries version 2.4.0 required some code rework on our Nano boards. Nothing major, and we got my first node up and running using OTA.

Kinds regards,

Paul.

So, just to clear things up: TTN no longer supports the DIY single channel gateways based on

Is this correct? Can someone please give a definite answer?

I have setup an RPI-based gateway, have registered it on TTN but shows up as not connected. The gateway sends status reports in the form of udp packets properly as I am able to catch them using a custom udp sink.

@networthings it is supported as uplink, but it shows as “not connected” as that Single Channel Gateway implementation does not support downlink. It’s just not capable enough to include it as connected gateway; we can’t do joins or acks from the network.

We’re working towards a reference design where SCGs use a dedicated frequency (not the default join channels) and support downlink. Those will show up as connected, probably indicating it’s a SCG. Uplink-only SCGs are deprecated and not supported.

Another issue with that implementation is that a) it uses a hard coded IP address and b) it’s the old croft IP address.

Ok. Thanks for the clarification.

Does it mean that I should be able to see the traffic (e.g., status reports) from the gateway on TTN (the server IP is set to the proper router), or this will not work at all? In my case, I do not see anything on TTN.

@networthings status messages are not part of gateway traffic. You should see uplink messages.

Now that Croft has been obsolete and down for a long time, you should use the right router. Traffic to that IP address is going nowhere.

Best is to use the DNS name, but for testing it’s fine to use an IP address. See New addresses for cloud services: update your gateways

@johan Would the following be correct for a single_channel gw: on the console it will no longer show time since ‘last seen’ but despite that I should be able to see upllink traffic messages? For me that is not the case, I see no traffic anylonger.