All the other activity above is very worthwhile, but the heart of the matter is you don’t appear to be in contact with the TTN servers - so you need to check your internet connectivity and particularly your DNS entry.
resolv.conf is not an output of compilation of the packet forwarder, it’s a settings file.
Think i can see the problem, you are using the Gateway EUI derived from the SX1302. I can tell as the centre bytes are “01FF”
if you read my post from June you will see I discussed this very problem when you use this type of MAC address
I also notice the SX1302 chip has its own EUI, from what I can see this is new to the SX1302 chip. So instead of deriving the gateway EUI from the Ethernet MAC, the gateway chip has its own EUI. Now its format is slightly different, instead of the two centre bytes being FF FE, in my case they were 01 FF. When I used this as the Gateway ID the TTN server would work fine, data packets from a Node would pass to the Application Server, the modified
Stat Intervaldatagram would work and the Console’s “Last Seen” would update correctly, HOWEVER, the server does not send an acknowledgement packet to theKeep Alivedatagram.
The solution is to create a gateway EUI with the traditional FFFE in the middle.
Find the MAC address of the Raspi ethernet and insert FFFE in the middle and register this in global_conf.json as below. Also don’t forget to register this gateway at TTN.
"gateway_conf": {
"gateway_ID": "xxxxxxFFFExxxxxx",
Find the MAC address of the Raspi ethernet
Sorry sir, but I do not know how to find the MAC address. Is it through running the program or just can view it directly?
# Generated by resolvconf
nameserver 192.168.3.1
nameserver fe80::2ec5:46ff:feb3:4e7b%wlan0
I can see something, maybe it didn’t go wrong.
From the command line on the Raspi type “ifconfig” and it will display the IP address and MAC address of the ethernet port, WiFi port and others. The ethernet port will be listed as eth0: and the MAC address is after “ether”, see bold below
eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
inet 192.168.1.52 netmask 255.255.255.0 broadcast 192.168.1.255
ether 4e:ff:eb:2d:xx:xx txqueuelen 1000 (Ethernet)
pi@raspberrypi:~ $ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether dc:a6:32:ae:4d:38 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
*** 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
INFO: global_conf.json does contain a JSON object named SX130x_conf, parsing SX1302 parameters
INFO: spidev_path /dev/spidev0.0, lorawan_public 1, clksrc 0, full_duplex 0
INFO: antenna_gain 0 dBi
INFO: Configuring legacy timestamp
INFO: Configuring Tx Gain LUT for rf_chain 0 with 16 indexes for sx1250
INFO: radio 0 enabled (type SX1250), center frequency 474600000, RSSI offset -207.000000, tx enabled 1, single input mode 1
INFO: radio 1 enabled (type SX1250), center frequency 475400000, RSSI offset -207.000000, tx enabled 0, single input mode 1
INFO: Lora multi-SF channel 0> radio 0, IF -300000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 1> radio 0, IF -100000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 2> radio 0, IF 100000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 3> radio 0, IF 300000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 4> radio 1, IF -300000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 5> radio 1, IF -100000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 6> radio 1, IF 100000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 7> radio 1, IF 300000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7, Explicit header
INFO: FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate
INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to DCA632FFFEAE4D38
INFO: server hostname or IP address is configured to "asia-se.thethings.network"
INFO: upstream port is configured to "1700"
INFO: downstream port is configured to "1700"
INFO: downstream keep-alive interval is configured to 10 seconds
INFO: statistics display interval is configured to 30 seconds
INFO: upstream PUSH_DATA time-out is configured to 100 ms
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
INFO: Beaconing period is configured to 0 seconds
INFO: Beaconing signal will be emitted at 869525000 Hz
INFO: Beaconing datarate is set to SF9
INFO: Beaconing modulation bandwidth is set to 125000Hz
INFO: Beaconing TX power is set to 14dBm
INFO: Beaconing information descriptor is set to 0
INFO: global_conf.json does contain a JSON object named debug_conf, parsing debug parameters
INFO: got 2 debug reference payload
INFO: reference payload ID 0 is 0xCAFE1234
INFO: reference payload ID 1 is 0xCAFE2345
INFO: setting debug log file name to loragw_hal.log
CoreCell reset through GPIO7...
INFO: Configuring SX1250_0 in single input mode
INFO: Configuring SX1250_1 in single input mode
INFO: [main] concentrator started, packet can now be received
INFO: concentrator EUI: 0x0016c001ff10d3f6
##### 2020-11-10 13:31:35 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 0 (0 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
### SX1302 Status ###
# SX1302 counter (INST): 30730218
# SX1302 counter (PPS): 0
# BEACON queued: 0
# BEACON sent so far: 0
# BEACON rejected: 0
### [JIT] ###
src/jitqueue.c:442:jit_print_queue(): INFO: [jit] queue is empty
#--------
src/jitqueue.c:442:jit_print_queue(): INFO: [jit] queue is empty
### [GPS] ###
# GPS sync is disabled
##### END #####
JSON up: {"stat":{"time":"2020-11-10 13:31:35 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0}}
There is still no connection, but I have to thank you for your continuous enthusiastic response.
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”