If there is one it will be the cause of your issues as that will still point to V2 overriding the V3 settings.
I do have a local_conf.json file:
{
"gateway_conf": {
"gateway_ID": "xxxxxxxxxxxxxxxx"
"server_address": "eu1.clodu.thethings.network",
}
}
Again, I have populated this with the same Gateway EUI as shown on the overview screen. This is very similar to the MAC address of the eth0 port on the pi (FF and FE added in the middle). I have 2 ports on the pi, eth0 and wlan0 (standard). When I initially set up the RAK gateway, the application selected the MAC address of eth0, presumably because I didn’t have wlan0 set up. Does it actually matter which port is selected?
Also, since enabling wlan0, I see that running gateway-config on the pi no longer announces the MAC address at the top of the menu as the Gateway ID:
I assume that Gateway ID = Gatway EUI, ie an 8 byte number? (at least this is what the software populated the menu with on initial setup)
Ditto running the gateway-version command. The Gateway ID on the pi is absent. So I maybe I have corrupted something. However, global_config.json and local_config.json match the settings in the overview section of the gateway in the browser.
Spelling error for the win!!!
It is a typo, but I transcribed the file from a putty terminal into the reply. The file is correct on the pi unfortunately!!
Thanks for the reply though…
Jimgi
So does it work now?
Regrettably no. I can’t see what I am doing wrong, but as I mentioned, the rack menu application and gateway-version command doesn’t return a Gateway ID (Gateway EUI)
Jimgi
Looks like you modified a file the RAK software depends on. I would take a fresh SDcard (so you can keep the current information and get back to it if required), flash it with a clean image and start over.
Yes, I thought that was worth doing, so flashed another SD card.
global_conf.json looks like this: ( I have obscured the gateway ID, but it was as generated as before, and is shown in the setup)
"gateway_conf": {
"gateway_ID": "xxxxxxxxxxxxxxxx",
"server_address": "eu1.cloud.thethings.network",
"serv_port_up": 1700,
"serv_port_down": 1700,
"servers": [
{
"gateway_ID": "xxxxxxxxxxxxxxxx",
"server_address": "eu1.cloud.thethings.network",
"serv_port_up": 1700,
"serv_port_down": 1700,
"serv_enabled": true
}
]
}
still no joy.
local_conf.json just has the gateway ID in it.
Jimgi
Right, now I’m curious what you entered in the V3 console. Could you post a screenshot without completely obscured EUI and ID? (Just obscure the last 4 digits if you need to)
I’ve lost track, what can we do if we know someones gateway EUI - because I can harvest them from my uplink meta data so it can’t all be top secret?
Just to confirm, the Gateway ID is the Gateway EUI field in the v3 console. And the RAK autogenerated id isn’t anything special to the hardware as such.
Minor butt, but when I put my PiSupply RAK833 on to v3 there was some uncertainty about what was or wasn’t working so I downloaded some handy packet forwarding software, compiled et voila. It is still lurking under the rubble on the desk so I can try stuff tomorrow.
OK, here is a screenshot of my Overview page:
The Gateway EUI is straight out of the pi application. The Gateway ID and description are just text strings that I supplied. Not derived from anything.
jimgi
And that same string minus spaces is in the global_conf.json and local_conf.json?
If not, replace the EUI with the value in the json files.
If they match, please post the log of the packet forwarder, the lines from startup of the forwarder up till the second repeating status block.
BTW, maybe stupid question, but does name resolving on the RPi work? And is there no firewall filtering port 1700 between the gateway and TTN? (Some UK ISPs filtered that port in the past, not sure if that is still the case, other ISPs around the world might implement this as well)
1 Like
Jac, @jimgi IIRC it was Virgin Media that had/has habbit of blocking port 1700… and I see jimgi’s IP address resolves to… virgin media. 
@jimgi give them a call and tell them you need port unblocking…they will complain and say it is done for their users benefit & safety as some remote control/remote admin software used by scammers etc. also uses same port…just remind them a) its not their job to sensor the internet, just implement allowed standards and provide you a suitable connection, b) tell them you also need to use for… remote control & admin s/w! If/when they allow you will likely then get a letter from another arm of VM saying hey we see your modem is unblocked and you/we need to close for security! (Left hand not knowing what right hand does!)…tell them to take a jump. Any issues tell them their services isnt fit for purpose (sale of good & services act - IANAL!) therefore you consider contract void and will move elsewhere at no cost. Others have managed to get round through similar routes…
I’m on Virgin Media and my gateways are OK. But worth checking connectivity.
The discovery server port is blocked but I just use a remote server for the few times I need to use that part of the CLI.
I’d still suspect there may be an issue with the RAK card image - I can take it for a spin later on this morning!
VM were/are inconsistent - it was more a problem 2-5 years back as havent seen it called out lately. I tried to map out where problems I heard about were located as suspected it when back to before the NTL/Telewest merger years back. NTL & TW were themselves meged networks from smaller providers and it looked like there was historic bias. I had a GW in Nottinham for several years until last summer were it was on VM no problem. What made it challenging to map as well was that in many places VM started offering BBand where they went ‘off net’ and used BT Openreach infrastructure, even where they had their own cable infra.
I’m with you in suspecting image at this point but still worth eliminating backhaul as a factor. A good test is to tether the GW to celluar via phone and see if that works…if it does then likely VM the boggeyman! 
@jimgi I noticed you said
Is that V2 GW on same network/backhaul? If so we know port1700 ok and VM not the issue and you can focus on the image 
I have a TTN gateway on that works in the same location, and connected to the same Virgin Media hub.
Yes, it is V2.
So must be the image…
@kersing - I will check the conf json files to make sure that the EUIs are correct, although I am pretty sure that they are.
Jimgi
As no one has acknowledged it, possibly I was too subtle, so I will repeat.
Back in early Feb my Pi + RAK833 was moved to v3 and did not appear to work.
So I downloaded @kersing’s packet forwarder and used that, which did work.
I don’t know if it was early days for the v3 stack (I doubt it) or something about the ancient code base on the Pi card.
I can re-run the experiment later on today.
I ran “tail -f syslog” and got the following output. If you scroll down to the bottom you can see that the system reports an error:
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: ERROR: [up] getaddrinfo on address eu1.cloud.thethings.network (PORT 1700) returned Temporary failure in name resolution
Could this be the port 1700 blocking by Virgin Media that we have been discussing?
I think that the very last error is the cntl-c to terminate the tail command.
jimgi
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Little endian host
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: found global configuration file global_conf.json, parsing it
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: lorawan_public 1, clksrc 1
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: no configuration for LBT
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: antenna_gain 0 dBi
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Configuring TX LUT with 16 indexes
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: radio 0 enabled (type SX1257), center frequency 867500000, RSSI offset -166.000000, tx enabled 1, tx_notch_freq 0
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: radio 1 enabled (type SX1257), center frequency 868500000, RSSI offset -166.000000, tx enabled 0, tx_notch_freq 0
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Lora multi-SF channel 0> radio 1, IF -400000 Hz, 125 kHz bw, SF 7 to 12
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Lora multi-SF channel 1> radio 1, IF -200000 Hz, 125 kHz bw, SF 7 to 12
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Lora multi-SF channel 2> radio 1, IF 0 Hz, 125 kHz bw, SF 7 to 12
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Lora multi-SF channel 3> radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Lora multi-SF channel 4> radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Lora multi-SF channel 5> radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Lora multi-SF channel 6> radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Lora multi-SF channel 7> radio 0, IF 400000 Hz, 125 kHz bw, SF 7 to 12
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: gateway MAC address is configured to B827EBFFFE5F5A60
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: server hostname or IP address is configured to "eu1.cloud.thethings.network"
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: upstream port is configured to "1700"
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: downstream port is configured to "1700"
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: downstream keep-alive interval is configured to 10 seconds
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: statistics display interval is configured to 30 seconds
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: upstream PUSH_DATA time-out is configured to 100 ms
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: packets received with a valid CRC will be forwarded
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: packets received with a CRC error will NOT be forwarded
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: packets received with no CRC will NOT be forwarded
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: GPS serial port path is configured to "/dev/ttyAMA0"
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Reference latitude is configured to 10.000000 deg
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Reference longitude is configured to 20.000000 deg
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Reference altitude is configured to -1 meters
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: fake GPS is disabled
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: Auto-quit after 20 non-acknowledged PULL_DATA
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: found local configuration file local_conf.json, parsing it
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: redefined parameters will overwrite global parameters
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: local_conf.json does not contain a JSON object named SX1301_conf
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: local_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: gateway MAC address is configured to B827EBFFFE5F5A60
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: packets received with a valid CRC will be forwarded
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: packets received with a CRC error will NOT be forwarded
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: packets received with no CRC will NOT be forwarded
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: INFO: [main] TTY port /dev/ttyAMA0 open for GPS synchronization
Sep 1 21:29:44 rak-gateway ttn-gateway[6578]: ERROR: [up] getaddrinfo on address eu1.cloud.thethings.network (PORT 1700) returned Temporary failure in name resolution
Sep 1 21:29:44 rak-gateway systemd[1]: ttn-gateway.service: Main process exited, code=exited, status=1/FAILURE
Sep 1 21:29:44 rak-gateway systemd[1]: ttn-gateway.service: Failed with result 'exit-code'.Not unless there are connection specific firewall rules in play on your router/modem given you have indicated that your other GW (on V2) is running fine as they will both be using Port 1700. Can you change ethernet ports with the other GW then we know we are clear?
Also just in case use the RPi WiFi to
As suggested above - you never know, but I suspect its more the GW firmware build/config…
No. That is a DNS error. Your gateway is not able to translate the name to an IP address. Log in to the gateway with SSH and run:
host eu1.cloud.thethings.network
That should show something like:
eu1.cloud.thethings.network has address 52.212.223.226
eu1.cloud.thethings.network has address 63.34.215.128
If it doesn’t you need to correct/setup the DNS settings on the RPi. (Google is your friend)