"Unable to fetch configuration from TTN" if cellular used

Gateways Raspberry Pi Gateways
1

Hello,
I’m using gateway with balena.io and https://github.com/jpmeijers/ttn-resin-gateway-rpi.

In case I connect the gateway using ethernet, everything is fine.
But if I use cellular modem, start fails with “Unable to fetch configuration from TTN. Are your GW_ID and GW_KEY correct?”
I can ping google from the container or curl https://account.thethingsnetwork.org/api/v2/frequency-plans/, so the cellular connection seems to be ok.
What is done exactly before this error message is thrown?

thanks and regards,
Thomas

root@c720441:~# balena logs xxx

Systemd init system enabled.
systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR)
Detected virtualization ‘other’.
Detected architecture ‘arm’.
Set hostname to .
mkdir: cannot create directory ‘/mnt/ramdisk’: File exists
ln: failed to create symbolic link ‘/opt/gwexporter/loragwstat.json’: File exists
INFO[0000] Starting node_exporter (version=0.16.0, branch=HEAD, revision=d42bd70f4363dced6b77d8fc311ea57b63387e4f) source=“node_exporter.go:82”
INFO[0000] Build context (go=go1.9.6, user=root@26eefbaf9294, date=20180515-15:55:44) source=“node_exporter.go:83”
INFO[0000] Enabled collectors: source=“node_exporter.go:90”
INFO[0000] - arp source=“node_exporter.go:97”
INFO[0000] - bcache source=“node_exporter.go:97”
INFO[0000] - bonding source=“node_exporter.go:97”
INFO[0000] - conntrack source=“node_exporter.go:97”
INFO[0000] - cpu source=“node_exporter.go:97”
INFO[0000] - diskstats source=“node_exporter.go:97”
INFO[0000] - edac source=“node_exporter.go:97”
INFO[0000] - entropy source=“node_exporter.go:97”
INFO[0000] - filefd source=“node_exporter.go:97”
INFO[0000] - filesystem source=“node_exporter.go:97”
INFO[0000] - hwmon source=“node_exporter.go:97”
INFO[0000] - infiniband source=“node_exporter.go:97”
INFO[0000] - ipvs source=“node_exporter.go:97”
INFO[0000] - loadavg source=“node_exporter.go:97”
INFO[0000] - mdadm source=“node_exporter.go:97”
INFO[0000] - meminfo source=“node_exporter.go:97”
INFO[0000] - netdev source=“node_exporter.go:97”
INFO[0000] - netstat source=“node_exporter.go:97”
INFO[0000] - nfs source=“node_exporter.go:97”
INFO[0000] - nfsd source=“node_exporter.go:97”
INFO[0000] - sockstat source=“node_exporter.go:97”
INFO[0000] - stat source=“node_exporter.go:97”
INFO[0000] - textfile source=“node_exporter.go:97”
INFO[0000] - time source=“node_exporter.go:97”
INFO[0000] - timex source=“node_exporter.go:97”
INFO[0000] - uname source=“node_exporter.go:97”
INFO[0000] - vmstat source=“node_exporter.go:97”
INFO[0000] - wifi source=“node_exporter.go:97”
INFO[0000] - xfs source=“node_exporter.go:97”
INFO[0000] - zfs source=“node_exporter.go:97”
INFO[0000] Listening on :81 source=“node_exporter.go:111”
*** Resin Machine Info:
*** Type: None
*** Arch: None

*** Configuration:

GW_EUI: xxx
Enabling TTN gateway connector

*** Fetching config from TTN account server

Unable to fetch configuration from TTN. Are your GW_ID and GW_KEY correct?
(node:164) DeprecationWarning: prom-client - Passing a non-object to metrics constructor is deprecated
Listening
root@c720441:~# ping google.com
PING google.com (172.217.22.78): 56 data bytes
64 bytes from 172.217.22.78: seq=0 ttl=50 time=142.171 ms
64 bytes from 172.217.22.78: seq=1 ttl=50 time=120.481 ms
64 bytes from 172.217.22.78: seq=2 ttl=50 time=140.293 ms
64 bytes from 172.217.22.78: seq=3 ttl=50 time=160.304 ms
64 bytes from 172.217.22.78: seq=4 ttl=50 time=138.552 ms
64 bytes from 172.217.22.78: seq=5 ttl=50 time=139.977 ms
^C
— google.com ping statistics —
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 120.481/140.296/160.304 ms
root@c720441:~# time

real 0m0.000s
user 0m0.000s
sys 0m0.000s
root@c720441:~# timedatectl
Local time: Fri 2019-03-22 18:09:41 UTC
Universal time: Fri 2019-03-22 18:09:41 UTC
RTC time: n/a
Time zone: n/a (UTC, +0000)
System clock synchronized: yes
systemd-timesyncd.service active: n/a
RTC in local TZ: no
root@c720441:~# wget https://account.thethingsnetwork.org/api/v2/frequency-plans/
Connecting to account.thethingsnetwork.org (104.40.216.89:443)
wget: can’t open ‘index.html’: Read-only file system
root@c720441:~# curl https://account.thethingsnetwork.org/api/v2/frequency-plans/
bash: cuurl: command not found
root@c720441:~# curl https://account.thethingsnetwork.org/api/v2/frequency-plans/
{“EU_863_870”:{“id”:“EU_863_870”,“name”:“EU_863_870”,“url”:“https://account.thethingsnetwork.org/api/v2/frequency-plans/EU_863_870",“description”:"Europe 868MHz”,“base_freq”:868},“US_902_928”:{“id”:“US_902_928”,“name”:“US_902_928”,“url”:“https://account.thethingsnetwork.org/api/v2/frequency-plans/US_902_928",“description”:"United States 915MHz”,“base_freq”:915},“AU_915_928”:{“id”:“AU_915_928”,“name”:“AU_915_928”,“url”:“https://account.thethingsnetwork.org/api/v2/frequency-plans/AU_915_928",“description”:"Australia 915MHz”,“base_freq”:915},“CN_470_510”:{“id”:“CN_470_510”,“name”:“CN_470_510”,“url”:“https://account.thethingsnetwork.org/api/v2/frequency-plans/CN_470_510",“description”:"China 470-510MHz”,“base_freq”:470},“AS_920_923”:{“id”:“AS_920_923”,“name”:“AS_920_923”,“url”:“https://account.thethingsnetwork.org/api/v2/frequency-plans/AS_920_923",“description”:"Asia 920-923MHz”,“base_freq”:915},“AS_923_925”:{“id”:“AS_923_925”,“name”:“AS_923_925”,“url”:“https://account.thethingsnetwork.org/api/v2/frequency-plans/AS_923_925",“description”:"Asia 923-925MHz”,“base_freq”:915},“KR_920_923”:{“id”:“KR_920_923”,“name”:“KR_920_923”,“url”:“https://account.thethingsnetwork.org/api/v2/frequency-plans/KR_920_923",“description”:"Korea 920-923MHz”,“base_freq”:915},“IN_865_867”:{“id”:“IN_865_867”,“name”:“IN_865_867”,“url”:“https://account.thethingsnetwork.org/api/v2/frequency-plans/IN_865_867",“description”:"India 865-867MHz”,“base_freq”:868},“RU_864_870”:{“id”:“RU_864_870”,“name”:“RU_864_870”,“url”:“https://account.thethingsnetwork.org/api/v2/frequency-plans/RU_864_870",“description”:"Russia 864-870MHz”,“base_freq”:868}}root@c720441:~# ^C

2

My guess: When I run from cellular, the cellular connection is not yet ready when the container is started so the connection attemp and the retry within 30sec by the application fails.
Is there a chance to wait with the container start until cellular is connected?
If I restart the container some minutes Raspberry runnung, the application container works fine.

I’m using Huawei MS2131 cellular adapter.

3

Fixed by adding an wait in case of cellular in application:

if os.environ.get(‘CELLULAR_WAIT’) != None:
cellular_wait_s = os.environ.get(‘CELLULAR_WAIT’)
cellular_wait_s = float(os.environ.get(‘CELLULAR_WAIT’))
print ("*** Wait time for cellular connnection in s: “+str(os.environ.get(‘CELLULAR_WAIT’)))
print (”*** Wait time for cellular connnection in s: "+str(os.environ.get(‘CELLULAR_WAIT’)))
time.sleep(cellular_wait_s)
time.sleep(cellular_wait_s)

1 Like
4

In practice mobile data connections will come and go in the field and may fail to establish for a while; you will probably ultimately need more sophisticated management able to handle such variation and react to failures in productive ways.

5

The repo used for balena uses MP forwarder which uses TCP with heartbeat, it will reconnect automatically if the connection is interrupted.

1 Like
6

Problem was only in initialization.

7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.