search

wb2osz / direwolf

Dire Wolf is a software "soundcard" AX.25 packet modem/TNC and APRS encoder/decoder. It can be used stand-alone to observe APRS traffic, as a tracker, digipeater, APRStt gateway, or Internet Gateway (IGate). For more information, look at the bottom 1/4 of this page and in https://github.com/wb2osz/direwolf/blob/dev/doc/README.md
GNU General Public License v2.0
1.53k stars 300 forks source link

Direwolf loses ability to resolve domain names #86

Closed johnboiles closed 7 years ago

johnboiles commented 7 years ago

I'm working on a cellular-enabled mobile igate that I can throw on my car when I'm chasing high altitude balloons (using johnboiles/pi-rtlsdr-igate-docker). Everything mostly works great, though I'm noticing that sometimes, on a network change or hiccup, Direwolf gets in a state where it can't resolve DNS. In the logs I see

Can't get address for IGate server noam.aprs2.net, Name or service not known

But if I open a ssh connection to the RaspberryPi while this is happening, and then run ping noam.aprs2.net, I am able to resolve to an IP and ping without issue.

Seems like DNS resolution should be handled by the system, so I'm not sure why this is happening. Perhaps Direwolf isn't trying again to resolve the domain once it fails once?

For me, a workaround would be to have a mode where Direwolf just closes when it has a networking issue like this. Then I can easily set it to restart with systemd.

Any help is much appreciated. I'm really digging Direwolf.

dranch commented 7 years ago

You can solve this a few ways. You can put a static DNS entry in the /etc/hosts file. You could also configure a caching DNS server on your Pi itself.

johnboiles commented 7 years ago

@dranch thanks for the idea. That's probably not a bad idea so save some lookups as the connection is going in and out. However, I think my issue is actually an artifact of running inside a Docker container, and totally unrelated to Direwolf. I found this in the Docker docs.

When the host [/etc/resolv.conf] changes, all stopped containers which have a matching resolv.conf to the host will be updated immediately to this newest host configuration. Containers which are running when the host configuration changes will need to stop and start to pick up the host changes due to lack of a facility to ensure atomic writes of the resolv.conf file while the container is running.

So that's very likely my issue: Docker is grabbing the local DNS configuration when the container starts, then if/when that changes the container isn't updated. I think the fix is to force Docker to use 8.8.8.8 for DNS via the --dns option. I won't know for sure until I get some time out in the wild to test.