Using Mesh Status, one of my nodes has (tun*1) after it in the listing.
What does that mean?
Bob W8ERD
What does that mean?
Bob W8ERD
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
(tun*?)
"(tun)" next to a Mesh Node in the "Current Neighbors" column indicates the path to the Neighbor is over an Internet tunnel. "(tun*?)" next to a mesh node in the "Remote Nodes" column indicates the node has tunnel links over the internet to connect mesh islands together. "?" is a number indicating the count of tunnel connections the node has.
But I don't have any tunnels, and have never had them.
Bob W8ERD
We did this with 2 different stations. If you turn off the wireless connection, the tun message persists until you reboot the mesh node.
This happened before I could collect the data you requested. If necessary we could do it again and collect the data.
Apparently it does not really hurt anything, but is misleading.
Bob W8ERD
You report that your [corrected] "tun" message doesn't go away [locally] until you reboot your node. This is consistent with other persistent (but no longer correct) messages having to do with Mesh Status reporting in 3.16.1.1. I've noticed the same behavior with changing service names or deleting services. Other nodes which have logged your service name/status earlier will NOT delete or change status (unless/until they reboot) just because of your reboot. It was brought to my attention in earlier posts here that you need to disconnect your node from the rest of your mesh for an extended period of time (20 mins???) - this allows all your data to "time-out" at all those remote nodes and then you start again fresh with the correct data. Hopefully the newer OSLR has fixed this ...
- Don - AA7AU
Joe
Bob W8ERD
Bob W8ERD
Bob W8ERD
Bob W8ERD
Internet, either wireless wifi or a second wired port, then tun* is displayed next to that node name on the mesh status screen, when viewed from a remote node.
The tun message persists forever, even if the PC is disconnected from the node. Only rebooting the node removes it. Here is the latest data, hopefully as you requested.
Bob, this is another symptom of the same root cause captured in this issue: https://github.com/aredn/aredn_ar71xx/issues/204
OLSR is not communicating hostnames across the mesh network, although it's config files tell olsr to do so. Specifically, in this example, OLSR is started with a config file, can find by "ps | grep olsr". You see "/usr/sbin/olsrd -f /var/etc/olsrd.conf ...". By inspection of /var/etc/olsrd.conf, you can see this section on W8ERD-Nano2:
LoadPlugin "olsrd_nameservice.so.0.4"
{
PlParam "sighup-pid-file" "/var/run/dnsmasq/dnsmasq.pid"
PlParam "interval" "30"
PlParam "timeout" "300"
PlParam "name-change-script" "touch /tmp/namechange"
PlParam "name" "W8ERD-Nano2"
PlParam "10.155.175.113" "dtdlink.W8ERD-Nano2.local.mesh"
}
This means on other nodes on the mesh network, there should be an entry in "/tmp/run/hosts_olsr" for dtdlink.W8ERD-Nano2.local.mesh:
10.155.175.113 dtdlink.W8ERD-Nano2.local.mesh # 10.154.175.113
But this entry is missing across the mesh network. The work around is to restart olsr and/or reboot this node: "/etc/init.d/olsrd restart" (and wait 30 sec or so for the routing to enable you to see the output). If after rebooting a node, you can find any pattern as to when it is missing or not, would be helpful information.
Joe AE6XE
and when. The erroneous tun message is not causing any operational problems that I can see.
Bob W8ERD
option A) restart olsr, from the command line of the node: "/etc/init.d/olsrd restart" (and wait 30 sec or so for the routing to enable you to see the output).
option B) reboot the node
Joe