While we have two active nodes here in Kingman, they're on the other side of a large hill from me and not accessible to anyone downtown. Requesting a tunnel to either the Las Vegas or Phoenix supernodes, or to the aggregated node in Needles, until we can get some more rf on mountains.
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
73, Chuck
Credentials received and working. Is this configuration meant to access other supernodes and their networks via the tunnel supernode? Currently, no other supernodes are accessible - just nodes connected via direct tunnel.
Hi, N7CPZ:
From http://n7cpz-hapaclite.local.mesh/a/status,
in the left margin navigation, click on the cloud.
73, Chuck
Thanks for your prompt responses to this. I took a bit of a break for the holidays and am circling back to this.
I can access the Cloud icon, but when I click on any other supernode in the resulting list, DNS can't resolve the address and attempting to navigate to the node times out.
Example:
Checking nslookup for ke5yzp-ntx-supernode.local.mesh, I get the following:
Server: localnode.local.mesh
Address: 10.121.129.193
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to localnode.local.mesh timed-out
Compare that with one of your nodes, which I can access from the same interface without issue:
Server: localnode.local.mesh
Address: 10.121.129.193
DNS request timed out.
timeout was 2 seconds.
Name: nc8q-supernode.local.mesh
Address: 10.118.39.84
I'm wondering if this is intended behavior or if there's something else going on.
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: ke5yzp-ntx-supernode.local.mesh
Address: 10.7.11.187
gelmce@HP-Laptop:~$ traceroute -q 1 -m 9 ke5yzp-ntx-supernode.local.mesh
traceroute to ke5yzp-ntx-supernode.local.mesh (10.7.11.187), 9 hops max, 60 byte packets
1 localnode.local.mesh (10.46.133.185) 2.751 ms
2 mid7.NC8Q-KETTERING-MVHS (172.31.57.36) 27.733 ms
3 dtdlink.NC8Q-SUPERNODE.local.mesh (10.118.39.80) 27.836 ms
4 mid7.N5MXI-STX-SUPERNODE (172.30.105.135) 95.516 ms
5 KE5YZP-NTX-SUPERNODE.local.mesh (10.7.11.187) 145.929 ms
gelmce@HP-Laptop:~$
N7CPZ:
I do not recall if this is fixed in a Nightly, but I had to use my supernode's address as one of my 2 DNS lookups
on an uplink node.
I use 8.8.8.8 and 10.118.39.84.
I see that your test included that IP address, so I do not know why the lookup failed.
However, yes, if your host uses nc8q-supernode or
my end of the tunnel (NC8Q-HAP-AC3,10.207.77.103),
in a DNS lookup,
every node on the World Map should resolve.
I think. :-|
73, Chuck
Thanks for looking at this first thing in the morning.
I tried a few variations on DNS: my node IP, the supernode IP, and the endpoint IP (in primary and alternate), then in combination with 1.1.1.1/8.8.8.8/my local DNS. Same results on all. Also updated the firmware to the latest nightly (20250102-74fc3712) with no change.
With the tools at my disposal from an endpoint it's hard to say where the problem is, other than hostnames aren't resolving on my end.
I feel like a lot of people would have said something if this was a legitimate bug, so I'm perplexed why it's behaving like this.
I shared my commands and results.
Hopefully someone will understand how to fix this and reply.
I am not familiar with nslookup.
I typically use 'route' and 'traceroute'.
Let us compare our configurations.
My tunnel server has DNS settings: 10.118.39.84, 8.8.8.8
I am tunneled into nc8q-hap-ac3.
You are tunneled into nc8q-hap-ac3.
My tunnel client has default DNS settings: 8.8.8.8, 8.8.4.4
Your tunnel client has DNS settings: 192.168.20.200 10.207.77.103(nc8q-hap-ac3)
I think the first host to do a lookup is the host,
2nd whatever IP address of the server that issued an IP address to the host,
3rd,4th IP addresses from a DNS lookup table.
Whatever uplink DNS lookups 3rd and 4th have.
73, Chuck
Eventually determined that DNS must be set to a Supernode in Windows IPv4 settings in order for this to work, rather than in node DNS. It maybe shouldn't be like that, but it's a viable workaround.
I thought that
if Windows gets an IP address from (anything, an AREDN node),
then that host automagically becomes one of the Window's DNS lookups.
73, Chuck