[arm-allstar] OLSR Hostname resolve

[David McGough]

Hi Ron,

The problem seems to be DNS related, where the hamvoip release runs a
local DNS server which is setup to resolve public URLs, and it doesn't
know how to find the private URLs you're requesting.

For my first suggestion, from a computer that does resolve DNS properly,
take a look at the contents of the /etc/resolv.conf file. I'm guessing
there -may- be a local, private nameserver listed (other than 127.0.0.1).  
If there is a local nameserver listed, just copy those resolv.conf file
contents to the RPi2 equivalent file, and you should be good to go.

By the way, I do recommend that you leave the RPi2 setup for a static IP 
address--not DHCP.

If this doesn't fix the issue, put the original /etc/resolv.conf file back 
on the RPi2, and I'll walk you through the steps to fix this the manual 
way.


73, David KB4FXC





On Thu, 24 Dec 2015 ron at morell.us wrote:

> I am having trouble configuring the network on the AllStar RPI under
> ARCH linux.  I originally went with DHCP and then not resolving host
> names, I went with Static, by running the netsetup.sh script.  DNS works
> fine, such as ping yahoo.com and so forth, but the OLSR host names are
> not resolving. The network in use is the HSMM-MESH network.
> http://hsmm-mesh.org/
> 
> The ping attempts look like this:
> 
> [root at allstar-ka7u ~]# ping ka7u-1
> ping: unknown host ka7u-1
> [root at allstar-ka7u ~]# ping ka7u-6
> ping: unknown host ka7u-6
> [root at allstar-ka7u ~]# ping allstar-ka7u
> PING AllStar-KA7U (127.0.0.1) 56(84) bytes of data.
> 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64
> time=0.149 ms
> 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64
> time=0.150 ms
> 
> >From a computer sharing the same switched LAN the hosts are resolved:
> 
> ron at linux-zdyj:~> ping ka7u-1
> PING ka7u-1.local.mesh (10.82.214.245) 56(84) bytes of data.
> 64 bytes from KA7U-1.local.mesh (10.82.214.245): icmp_seq=1 ttl=64
> time=0.913 ms
> 64 bytes from KA7U-1.local.mesh (10.82.214.245): icmp_seq=2 ttl=64
> time=0.687 ms
> ^C
> --- ka7u-1.local.mesh ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 0.687/0.800/0.913/0.113 ms
> ron at linux-zdyj:~> ping ka7u-2
> PING ka7u-2.local.mesh (10.130.192.42) 56(84) bytes of data.
> 64 bytes from KA7U-2.local.mesh (10.130.192.42): icmp_seq=1 ttl=63
> time=2.19 ms
> 64 bytes from KA7U-2.local.mesh (10.130.192.42): icmp_seq=2 ttl=63
> time=1.82 ms
> ^C
> --- ka7u-2.local.mesh ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 1.822/2.010/2.199/0.193 ms
> ron at linux-zdyj:~> ping allstar-ka7u
> PING allstar-ka7u.local.mesh (10.45.111.86) 56(84) bytes of data.
> 64 bytes from AllStar-KA7U.local.mesh (10.45.111.86): icmp_seq=1 ttl=64
> time=0.343 ms
> 64 bytes from AllStar-KA7U.local.mesh (10.45.111.86): icmp_seq=2 ttl=64
> time=0.276 ms
> ^C
> PING allstar-ka7u.local.mesh (10.45.111.86) 56(84) bytes of data.
> 64 bytes from AllStar-KA7U.local.mesh (10.45.111.86): icmp_seq=1 ttl=64
> time=0.340 ms
> 64 bytes from AllStar-KA7U.local.mesh (10.45.111.86): icmp_seq=2 ttl=64
> time=0.310 ms
> 64 bytes from AllStar-KA7U.local.mesh (10.45.111.86): icmp_seq=3 ttl=64
> time=0.318 ms
> 64 bytes from AllStar-KA7U.local.mesh (10.45.111.86): icmp_seq=4 ttl=64
> time=0.313 ms
> ^C
> --- allstar-ka7u.local.mesh ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 2999ms
> rtt min/avg/max/mdev = 0.310/0.320/0.340/0.017 ms
> ron at linux-zdyj:~>
> 
> I imagine this isn't the right place to pose this plea for assistance,
> but I'm not sure where else to go to configure networking in ARCH Linux.
>  I have background in Debian and openSUSE, but they do networking
> differently.
> 
> Any ideas? This problem might be the root cause of my failure to form a
> 2-way simple bridge between Asterisk servers. I can call extensions on
> the AllStar-KA7U server from the KA7U-2 server, but not the other way
> around. The problem might not be this resolve failure as it might be the
> older Asterisk version in AllStar not navigating the NAT properly, but
> one shortcoming at a time...
> 
> Ron Morell
> KA7U
> 
> 
> 
> 
> _______________________________________________
> 
> arm-allstar mailing list
> arm-allstar at hamvoip.org
> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> 
> Visit the BBB and RPi2 web page - http://hamvoip.org
>