That doesn’t show us your DNS entry (cat /etc/resolv.conf) and it appears you only have IP6 configured - is there some form of gateway / translation on to the internet at large?
What does pinging a known host get you?
pi@raspberrypi:~ $ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.3.1
nameserver fe80::2ec5:46ff:feb3:4e7b%wlan0
I can ping my own Alibaba Cloud server:
pi@raspberrypi:~ $ ping 47.110.36.225
PING 47.110.36.225 (47.110.36.225) 56(84) bytes of data.
64 bytes from 47.110.36.225: icmp_seq=1 ttl=51 time=295 ms
64 bytes from 47.110.36.225: icmp_seq=2 ttl=51 time=252 ms
64 bytes from 47.110.36.225: icmp_seq=3 ttl=51 time=138 ms
64 bytes from 47.110.36.225: icmp_seq=4 ttl=51 time=259 ms
64 bytes from 47.110.36.225: icmp_seq=5 ttl=51 time=232 ms
64 bytes from 47.110.36.225: icmp_seq=6 ttl=51 time=306 ms
64 bytes from 47.110.36.225: icmp_seq=7 ttl=51 time=270 ms
64 bytes from 47.110.36.225: icmp_seq=8 ttl=51 time=198 ms
64 bytes from 47.110.36.225: icmp_seq=9 ttl=51 time=217 ms
64 bytes from 47.110.36.225: icmp_seq=11 ttl=51 time=238 ms
64 bytes from 47.110.36.225: icmp_seq=12 ttl=51 time=202 ms
64 bytes from 47.110.36.225: icmp_seq=13 ttl=51 time=186 ms
64 bytes from 47.110.36.225: icmp_seq=14 ttl=51 time=252 ms
64 bytes from 47.110.36.225: icmp_seq=15 ttl=51 time=231 ms
64 bytes from 47.110.36.225: icmp_seq=17 ttl=51 time=267 ms
^C
--- 47.110.36.225 ping statistics ---
17 packets transmitted, 15 received, 11.7647% packet loss, time 166ms
rtt min/avg/max/mdev = 137.982/236.222/306.036/42.230 ms
However, I cannot ping the asia-se.thethings.network:
pi@raspberrypi:~ $ ping 13.76.41.40
PING 13.76.41.40 (13.76.41.40) 56(84) bytes of data.
^C
--- 13.76.41.40 ping statistics ---
16 packets transmitted, 0 received, 100% packet loss, time 592ms
OK, so we know you have basic connectivity - you can’t ping the clusters, they are behind load balancers so that’s quite normal.
However I see you used an IP address so we don’t really actually know if your DNS is active
So try pinging something by name please
I ping a search engine in China, and it works well.
pi@raspberrypi:~ $ ping www.baidu.com
PING www.a.shifen.com (180.101.49.11) 56(84) bytes of data.
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=1 ttl=55 time=293 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=2 ttl=55 time=309 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=3 ttl=55 time=258 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=4 ttl=55 time=224 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=5 ttl=55 time=274 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=6 ttl=55 time=262 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=7 ttl=55 time=227 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=8 ttl=55 time=182 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=9 ttl=55 time=235 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=10 ttl=55 time=299 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=12 ttl=55 time=282 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=13 ttl=55 time=289 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=14 ttl=55 time=310 ms
^C
--- www.a.shifen.com ping statistics ---
15 packets transmitted, 13 received, 13.3333% packet loss, time 436ms
rtt min/avg/max/mdev = 182.291/265.061/310.472/36.998 ms
I find this theory that certain patterns are disallowed rather dubious.
But if it is true, then it should be something that can be confirmed setting such a suspect eui in an ordinary SX1301 packet forwarder, too.
I agree, however back in June this was the case, equally why would adding temperature as an extra data element to the JSON string make it fail.
I was reporting my experience on the Mesh server and the issue here is on the SE Asia server. Remember the servers are not all the same, for example, there are a number of Integrations that don’t work off Meshed.
Essentially we were offering some options to explore not know if they applied to the SE Asia server or not. I may also repeat the tests on Meshed and see if its different now.
The problem is that a “lore” of unconfirmed suspicions causes people to waste a lot of time trying things without really knowing if they help. That’s magic, not engineering.
If there’s actual a problem with certain EUI patterns, then it’s a problem that can be confirmed using some other sort of packet forwarder, like a standard SX1301 setup.
That would be in contrast to something like say, a bug in the packet forwader, where it might use a different EUI in different situations (though lets hope anything so extreme would have been quickly caught).
why would adding temperature as an extra data element to the JSON string make it fail.
That would be another unconfirmed guess. A JSON parser is not supposed to care about additional fields. Though an implementation that had a fixed length buffer somewhere could choke on a longer message than previously seen. But again that’s something that could be confirmed, for example by modifying a standard packet forwarder to send a few extra bogus fields.
The community is served by having confirmed factual knowledge of issues. In addition to a confirmed dependence on specific gateway-side behavior, any real issue should be recognizable in the server source code, knowable aspects of Internet protocols, etc.
Hi, its not a guess, when I modified the SX1302 packet forwarder code last June and removed the temperature field it fixed the problem.
Reasonable idea. Over the next few days I’ll see if I can get the time to do this.
Hi @cslorabox, Am I a Magician or an Engineer? 
To assist, I have repeated the tests performed and reported in June (link provided above) as well as extending these to the V3 platform. I will report on these shortly.
Would be interested to compare these results with tests you could perform on your local server.
I have replicated the issue in the V3 stack and its the same as I found last June.
I’m sure this will be resolved in the longer term, but for now I’ve published a modified packet forwarder.
A more detailed description of the issue can be found on GitHub and its associated with the use of V1.3 of the gateway-to-server protocol.
It also includes a second patch to address the problem where the gateway radio module does not have a stts751 temperature sensor.
Presumably you mean the theory that the temperature field is causing an issue.
Your repo would be a lot more useful if in its commit history you identified where it forked from Semtech’s code (indeed, if you retained rather than eliminated Semtech’s commit history) and then had a single well-titled commit making the functional changes you feel are appropriate.
As I posted last week, I would be interested to see if this can be repeated on another server. I’ve only tried this on the Meshed server and more recently on a V3 instance running on The Things Industries.
I’ll have a look at taking on your suggestion re the Repo, in the interim I’ve deleted the Repo and will have another try.
When I use the global.conf and lora_pkt_fwd above, there is an error.
pi@raspberrypi:~/gw1302s/bin $ ./lora_pkt_fwd
*** Packet Forwarder ***
Version: 1.0.5
*** SX1302 HAL library version info ***
Version: 1.0.5;
***
INFO: Little endian host
INFO: found configuration file global_conf.json, parsing it
ERROR: global_conf.json is not a valid JSON file
Did you edit the global_config.json file and insert your own gateway ID?
this file has the following which needs to be changed
“gateway_ID”: “Place your gateway ID here”
Yes I did, and
When I use your global.conf and my own lora_pkt_fwd, it has the same error above.
When I ues my own global.conf and your lora_pkt_fwd, it has another error:
ERROR: invalid I2C file descriptor
ERROR: invalid I2C file descriptor
ERROR: failed to configure the temperature sensor
ERROR: [main] failed to start the concentrator
pi@raspberrypi:~/gw1302s/bin $ ./lora_pkt_fwd
Can you try two things with the combination of your global_config.json (with the 3 extra commands added) and my lora_pkt_fwd.
I suspect it has a temp sensor either not at the standard address or not the same type of sensor
- on the Raspberry Pi terminal run the command
sudo i2cdetect -y 1and see if you have a sensor at address 3b - in the global_config.json can you set the “temperature_sensor”: false,
My bad, just found an error in my global_config.json
The comment line below did not have the */ at the end. It should look like the following
/* if the following line is missing but required, the default value is 20.0C */
When I use my own lora_pkt_fwd and your global.config, I can communicate normally, but I can’t see the ‘Status：connection’. When I remove the temperature related code in lora_pkt_fwd , I can see ‘Status：connection’.
Next, I will use the control variable method to achieve a successful connection on the Japanese server.
By the way, in the global.config, I set the ‘gateway_ID’ the same as the ‘concentrator EUI’, and I do not use ‘FF FE’ and something like that.
The issue why the server rejects packets with the temp variable has been identified by TTN.
In the V3 stack it is coded as a signed integer while the SX1302 UDP packet forwarder, which is based on version v1.3 of the gateway-to-server protocol, is a float.
This can be seen in the open source code for the V3 stack on Line 118 of the link below.
While a future version of the V3 stack will be adjusted I would not expect the current V2 server to be modified given the freeze on making changes.
2 Likes
Is it possible to solve this problem simply by changing the variable type of variable temperature in lora_pkt_fwd.
1 Like