Considering you aren’t seeing any return traffic you need to check if there are any firewalls between the gateway and the TTN infrastructure.
Do you have a link to the airvent that you posted on the hard RAK831 cafe part 2?
sure 
hi @kersin good afternoon,
it is a simple network with a DSL router nothing else.
I also checked that there is no firewall set that could interfere.
Any other ideas? 
Some providers filter port 1700. Do you have some internet connected Linux server where you can run ‘nc’? Then you could modify the global_conf to send data to that server and use nc to check if it arrives.
@kersing, hi
As you suggested I modified the “global_conf” of my RPi located at Point A to send all the UDP packets to other server located in another country (Point B).
On the server side I created a small python script to listen to all the incoming data and as you can see in the screenshots I was successful.
On the left is the RPi3 and on the right the server I created to receive all the data from the GW.
Now that I have done this test I can confirm that the UDP packages are leaving the GW correctly.
So, my question now is: should I try connecting to another router instead of “brazil.thething.network”?
Thanks!
Using your python program, can you extend it to return a packet to the gateway? (Use an empty UDP packet and tcpdump on the gateway to check if it arrives)
Hi @kersing,
I added the confirmation on the server side and it works fine both ways.
So I think that my network configuration is not an issue.
I do not know how to proceed…should I try accesing TTN using another server?
I think that the servers are working fine. After trying that I set the server to
“eu.thethings.network” and executed tcpdump again.
If you inspect the first line after the timestamp, what is printed matches with the one from the first picture and the one after that should be the reply from the GW.
The only thing I can think of right now being the problem is TTN not accepting the packet for some reason. It could be the originating IP is blocked at TTN or the packets are malformed.
You could try building and running mp_pkt_fwd, that uses TCP to connect to the back-end (if configured to use server_type ‘ttn’)
Sure, give a few minutes I will have a look at the repo’s documentation on how to run it. And will write you back.\
Update:
I cloned the “mp_pkt_fwd” repo to mi /home/pi directory and executed “build-pi.sh”. After that the executable “mp_pkt_fwd” appeared in “/opt/ttn-gateway”.
I stopped ttn-gateway with “sudo service ttn-gateway stop” and executed the logs were
17:55:03 *** Multi Protocol Packet Forwarder for Lora Gateway ***
Version: 3.0.20
17:55:03 *** Lora concentrator HAL library version info ***
Version: 5.0.1; Options: native;
17:55:03 INFO: Little endian host
17:55:03 INFO: found local configuration file local_conf.json, parsing it
17:55:03 INFO: local_conf.json does not contain a JSON object named SX1301_conf
17:55:03 INFO: local_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
17:55:03 INFO: gateway MAC address is configured to B827EBFFFE3EF015
17:55:03 INFO: Found 1 servers in array.
17:55:03 INFO: Server 0 configured to “eu.thethings.network”
17:55:03 INFO: packets received with a valid CRC will be forwarded
17:55:03 INFO: packets received with a CRC error will NOT be forwarded
17:55:03 INFO: packets received with no CRC will NOT be forwarded
17:55:03 INFO: Reference latitude is configured to -27.364722 deg
17:55:03 INFO: Reference longitude is configured to -55.893333 deg
17:55:03 INFO: Reference altitude is configured to 0 meters
17:55:03 INFO: GPS is disabled
17:55:03 INFO: Upstream data is enabled
17:55:03 INFO: Downstream data is enabled
17:55:03 INFO: Ghoststream data is disabled
17:55:03 INFO: Radiostream data is enabled
17:55:03 INFO: Statusstream data is enabled
17:55:03 INFO: Beacon is disabled
17:55:03 INFO: Packet logger is disabled
17:55:03 INFO: Flush output after statistic is disabled
17:55:03 INFO: Flush after each line of output is disabled
17:55:03 INFO: Watchdog is disabled
17:55:03 INFO: Contact email configured to "@gmail.com"
17:55:03 INFO: Description configured to “First TTN of Posadas”
17:55:03 INFO: [Transports] Initializing protocol for 1 servers
17:55:03 INFO: Successfully contacted server eu.thethings.network
17:55:03 INFO: [main] Starting the concentrator
17:55:06 ERROR: [main] failed to start the concentrator
Good morning,
I modified the server address from “eu.thethings.network” to -> “router.eu.thethings.network” and now I get PULL_ACK in these logs":
INFO: Successfully contacted server router.eu.thethings.network
INFO: [main] Starting the concentrator
INFO: [main] concentrator started, radio packets can now be received.
INFO: [up] Thread activated for all servers.
INFO: [down] Thread activated for all server router.eu.thethings.network
INFO: [down] for server router.eu.thethings.network PULL_ACK received in 294 ms
INFO: [down] for server router.eu.thethings.network PULL_ACK received in 294 ms
INFO: [down] for server router.eu.thethings.network PULL_ACK received in 294 ms
Does this mean that now I am receiving ACK from the server?
Starting the packet forwarder without resetting the concentrator (which is usually done in a start script) will cause this message to appear. It might even appear a few times when you reset the concentrator. Just retry a couple of times.
That looks healthy. The gateway should now be listed active in the TTN console.
Hello everyone! GOOD NEWS! 
so after I modified the server address I started receiving PULL_ACK so I got closer to fix my issue.
I deleted the GW from the console and created it again, but this time I made sure that all the data such as email, and EUI matched (lowercase and uppercase) and issued
sudo service ttn-gateway restart
and suddenly appeared in the console as CONNECTED.
to verify that executed:
netstat -u
pi@unam:~ $ netstat -u
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 576 0 unam:40525 52.169.76.203:1700 ESTABLISHED
udp 0 0 unam:37002 52.169.76.203:1700 ESTABLISHED
Special thanks to @Edzelf and @kersing for the support you provided!
1 Like
coisa boa 
e!
Due to popular demands, I added some GPS and RTC features to RAK831 Pi Zero shield https://github.com/hallard/RAK831-Zero
List of V1.5a news:
-
Added connector to put a Tiny GPS breakout board
-
Added switch/jumpers to select PI Serial to be connected to FTDI connector or from GPS RX/TX
-
Added footprint for RTC components or Adafruit Breakout than you can plug upside or downside depending how you plug the Pi Zero. This is usefull when used with local LoRaWAN server without Internet connexion.
-
Added a LED on GPIO26 to light when GW is off so we can remove power safely (or whatever purpose)
-
Connected GPS PPS signal on GPIO4 and added a LED on this signal
Checkout the repo here you’ll be able to order new PCB (untested yet). I need to receive the boards to update doc with GPS config and RTC
Have fun and check tutorial of Andreas about this shield.
4 Likes
Awesome, I can’t wait to get my hands on them.
1 Like
Just updated to 1.5b for those who don’t want to solder SMD RTC, now you can plug (up or down) the cheap Adafruit RTC board, this mean it’s now as simple as plugging 2 breakouts, one for GPS and one for RTC. Of course if you have GPS one, you can sync time from GPS and avoid using a RTC.
2 Likes
RAK announces new Heatsink for RAK831
The included link forwards to here but the heatsink is not (yet) listed.
3 Likes