You are here

tun message

22 posts / 0 new
Last post
w8erd
tun message
Using Mesh Status, one of my nodes has (tun*1) after it in the listing.
What does that mean?

Bob W8ERD
AE6XE
AE6XE's picture
buried in the node's help
buried in the node's help file:

(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.

w8erd
tun message
Thanks for the reply. 

But I don't have any tunnels, and have never had them.

Bob W8ERD
AE6XE
AE6XE's picture
bob,  send a screen shot of
bob,  send a screen shot of this showing in mesh status.  Also on the node in question, can you attached a support download?
w8erd
tun message
Further experimentation shows that if you have a PC connected to a node, and you also have a wireless connection to the internet, then the tun message appears.
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
AA7AU
AA7AU's picture
Mesh Status message persistance

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

AE6XE
AE6XE's picture
Bob, what do you mean by
Bob, what do you mean by "wireless connection to the internet".   A node only has a physical internet connection on the WAN interface.  

Joe
w8erd
tun message
The PC is connected to the node with a wired connection. It is also connected to the internet via a wireless wifi connection.
 
K5DLQ
K5DLQ's picture
Bob, can you post a
Bob, can you post a screenshot of your /cgi-bin/status screen?
 
w8erd
tun message
Is that the typical mesh status screen?  If not, please tell me how to get to the screen you mention.

Bob W8ERD
K5DLQ
K5DLQ's picture
http://localnode:8080/cgi-bin
w8erd
tun message
Unfortunately it says I do not have permission to get to cgi-bin

Bob W8ERD
 
w8erd
tun message
Forgot the /status. Here it is with that.  Attached.

Bob W8ERD
Image Attachments: 
K5DLQ
K5DLQ's picture
Thanks.  
Thanks.  
AE6XE
AE6XE's picture
mesh status screen shot?
Bob, is there also a screen shot of the mesh status page, where you see an unexpcted "(tun*?)" entry?   Also, ideally, a support download from the node of the unexpected entry?   
w8erd
tun message
Attached is a screen shot showing the tun message and the support data fie from the same node.

Bob W8ERD
Image Attachments: 
Support File Attachments: 
AE6XE
AE6XE's picture
Bob thanks.  Sorry, should
Bob thanks.  Sorry, should have asked the 1st round.  Also need the support data for the node displaying the tun*1 to see the full picture.  Nothing is jumping ou t on w8erd-nano2 node yet. 
w8erd
tun message
Here is he latest. Just to recap.  Whenever a PC is logged into a node via a direct connection, and that PC also has a separate connection to the
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.
Image Attachments: 
Support File Attachments: 
K5DLQ
K5DLQ's picture
Mesh Status is http:/
AE6XE
AE6XE's picture
Bob, this is another symptom

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 

w8erd
tun message
Joe - I don't understand any of the OLSR messages.  If you would like me to perform any more tests, please give me the exact syntax of what I need to type
and when.  The erroneous tun message is not causing any operational problems that I can see.

Bob W8ERD
AE6XE
AE6XE's picture
Bob,  to make the symptom go
Bob,  to make the symptom go away, on  Nano-1 and Nano-2 nodes,  do one the following:

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

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer