New setup and get the below error. can’t ping google but can ping ip address. So certainly looks DNS.
In nameserver i have 127.0.0.1 and if I change this to the router 192.168.1.1 then it resolves domain names and pings. Great. then I get another error saying
RROR: [main] failed to start the concentrator
Jul 20 17:21:41 rak-gateway systemd[1]: ttn-gateway .service: Main process exited, code=exited, status=1/FAILURE
Jul 20 17:21:41 rak-gateway systemd[1]: ttn-gateway .service: Failed with result ‘exit-code’
ERROR: [up] getaddrinfo on address router.eu.thethings.network (PORT 1700) returned Temporary failure in name resolution
Restart the device and it removes my name server and just leaves the 127 address.
Having 127.0.0.1 as a name server means it’s pointing back to itself and even if you had a DNS daemon running, it wouldn’t be able to talk to the outside world as it would be pointing back on itself.
Remove the 127 from resolv.conf and just have your router, if that provides name servers (many do) or temporarily use the Google public DNS on 8.8.8.8
Indeed, this is how the majority of modern systems are configured
Incorrect. The local caching DNS has configuration elsewhere which is supposed to determine where it looks for answers it does not have, and that is supposed to be set up in your static network configuration or when you get your DHCP lease.
You overlooked that the asker already tried that and it only worked temporarily - you’re not supposed to edit /etc/resolv.conf on a system with local caching DNS and any change is likely to be reverted at the next boot if not earlier.
Look at the actual contents of /etc/resolv.conf on a modern Linux and you’ll probably see something like this:
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
If you want to manually set your own nameservers, first you’d need to find and disable whatever is going to keep undoing your efforts turning /etc/resolv.conf back into a symlink into a file managed by the local caching DNS daemon.
If it’s systemd (what I suspect you’ll find on a recent raspbian and derivatives) then the man page above would be a start. On openwrt (eg RAK’s smaller non-pi gateways rather than what the asker is facing) it’s probably something in init.d or uci-defaults.
In reality though, you’re better off working with how the system was designed to work, than fighting it.
First thing I’d do is figure out what version of raspbian (and underlying debian) or whatever RAK started with, next is figure out if they changed any of this or if it’s the way that distro is supposed to work. Then start looking for answers in general debian and rapsberry pi resources.
Whilst I concede that I’m no SysDev, I’ve not had these sorts of issues with a Pi unless the resolv.conf was empty or pointed to the wrong place - indeed, I have a client with a £40,000 piece of kit that resets it’s resolv.conf every time it’s rebooted and apparently only I know how to change it to point to the proper servers.
I did see that the OP had tried an external server, or rather his router, but as he said it removes my name server and just leaves the 127 address. I inferred that he was leaving the 127 address in and I was suggesting using a known good DNS.
No, the OP’s change to a file that you are not supposed to manually edit on a modern Linux, is being automatically reverted.
If you want to do things the old way, you have to first disable what maintains the operation of the built-in caching DNS, you can’t simply ignore that the system was set up to use it.
I’ve not had these sorts of issues with a Pi
You are likely using an earlier version of raspbian/debian where /etc/resolv.conf still works in the traditional way
On a system designed to use systemd-resolved, you do this by configuring systemd-resolved (and likely systemd-networkd) in accordance with the manual page and status commands quoted up the thread.
Not by making changes which the daemon will only undo.
I don’t have the OP’s particular pi image. I don’t like systemd’s attempt to take over every aspect of a system and debian maintainers going along with that. But I do know that crude edits won’t work on a system where this is set up to be automatically managed - you either work with that, or you change the system more fundamentally so that DNS is not automatically managed.
We don’t at this point know if this comes from RAK or from a newer Raspbian, but there’s enough oddness elsewhere in RAK’s software that taking a preferred or familiar version of Raspbian and installing the gateway components directly from Semtech’s repos oneself (making sure to change the SPI clock speed to 1 MHz) and the global_config.json from the TTN repo of such is perhaps the best strategy.