Strange 0.00 ETX entry in Remote Nodes List

12 posts / 0 new

Tue, 01/15/2019 - 14:38

AA7AU

My AirRouter is currently located in Las Vegas. It is connecting thru an M2 Rocket on my roof and then to Potosi and on. I just updated my AirRouter to last night's Nightly Build (thanks for some great new features). I have now found a very strange entry at the top of my Remote Nodes List (btw: I have this seen this [below] before on another node from someone else just recently). I do NOT have any tunnels or dtd links active.

This is what I'm now seeing at the top of this section, noname and 0.00 ETX, 4 hostnames and then all followed by over 1000 other more normal entries (now due to someone else's tunnel in place 3 or 4 hops away, between LV and Orange County):

Remote Nodes ETX Services
0.00
taxImac.local.mesh
kd7bbc-rk-dish-east-lan.local.mesh
kd7bbc-nb-dish-south-lan.local.mesh
kd7bbc-to-lake-m2.local.mesh

Is there anything else I can do or provide for troubleshooting?

Thanks!

- Don - AA7AU

File Attachment:

2019jan15-aa7au-airrouter-olsr.txt

Tue, 01/15/2019 - 18:34

AE6XE

Don, We see this when there

Don, We see this when there is a bad services entry. Find the owner of the services showing with node of ETX 0.0 and ask them to review their service definitions. This happens when someone reserves an IP address for a LAN device, but gave it the same name as the Node name -- an IP conflict. We have a recent change in the Nightly Build to check and prevent this from occurring.

Joe AE6XE

Thu, 03/19/2020 - 11:19

nc8q

Multiple identical Services with ETX 0.00

I am getting a different set of ten identical services with ETX 0.00 with each automatic refresh of the '/mesh' page via a tunnel connection. Except for my tunnel partner, every node exhibits this issue.

I may ask my tunnel partner to remove all service definitions.

Chuck

Image Attachments:

Thu, 03/19/2020 - 13:06

(Reply to #3) #4

AA7AU

Case Study for Naming conflicts

Hopefully that misconfigured node is on a small mesh island. With those non-unique names like IP-PHONE and RASPBX there are bound to be DNS conflicts. Sure wish folks would understand this better.

- Don - AA7AU

Thu, 03/19/2020 - 13:45

(Reply to #4) #5

nc8q

Hopefully that misconfigured node is on a small mesh island

Alas, nope. Total 1544 Nodes 469 I found 3 duplicates and about 33 ser4vice names that are apt to be duplicated. :-|

Thu, 03/19/2020 - 14:59

(Reply to #5) #6

AE6XE

If you upgrade to the nightly

If you upgrade to the nightly build images, mesh status no longer shows these entries. The root cause is this pesky olsr defect. Intermittently, OSLR fails to communicate the hostname and IP information in the hosts table passed across the mesh network. Mesh status is fixed to not show these bogus entries.

A workaround, is to go on to the node of the services and restart olsr -- in Advanced configruration, check the box and save for this OLSR row. It doesn't actually save anything, rather restarts OLSR without rebooting the node.

Symptoms when this needs done:

1) IP address shows on remote nodes instead of hostname. restart OLSR on the node of the IP address (not on the nodes where mesh status shows the IP address).
2) bogus ETX '0' entries in older images. restart OLSR on the node where the service was setup or advertised from.
3) bogus "tun" or other entry in mesh status. restart OLSR on the neighbor (not on the node where the bogus data shows).

Joe AE6XE

Thu, 03/19/2020 - 18:13

(Reply to #6) #7

nc8q

2) bogus ETX '0' entries in older images. restart OLSR

Hi, Joe:

Thanks.
What I am seeing is a different set of up to ten identical 'service-name.local.mesh ETX 0.00'
with each /mesh page refresh. See # 3 above.
There are 400+ nodes at http://pe1btv-client2.local.mesh:8080/cgi-bin/mesh
I found these callsigns among the 'ETX 0.00' under 'Remote Nodes':
NH6NN, W6VAH, AG6STO, AI6BX, AI6SW, KS6F, WI9EMT, AI6HJ, AK6PW;
but I cannot tell if a mis-configuration of advertised service reservation is causing this issue.
I will look longer and harder.

Chuck

Thu, 03/19/2020 - 18:37

AE6XE

Check how old of firmware are

Check how old of firmware are on these nodes. The UI used to allow a LAN device and service to have a conflicting hostname same as the node itself. This caused similar issues. In the current firmware, the UI no longer lets a user reserve a LAN IP address that would have a conflicting hostname with something else. (but it's been a while so hopefuly I have all the specifics correct.) Of course, there's no guarantee if someone had another device off the network and 2 people named a device with the same hostname, e.g. "raspi". i don't recall the exact symptoms of this, but it caused display issues in mesh status. check /tmp/run/hosts_olsr table to search for conflicting hostnames with different IP addresses. This might explain the situation.

Joe AE6XE

Thu, 03/19/2020 - 20:23

(Reply to #8) #9

nc8q

Check how old of firmware are on these nodes.

Thanks, Joe:

Well, there are 475 nodes in the table. I checked the top 20 by ETX at the tunnel node where I think the 'service.local.mesh ETX 0.00's are coming from:
35% 3.19.3.0
15% 3.16.1.1
15% 3.18.9.0
10% 3.16.1.0
05% NB 1190
05% BBHN 3.1.0 (!)
05% NB 1234
05% develop176

I SCP'ed hosts_olsr and services_olsr and did not find again the 3 service name duplications.
I found no host name duplications.

I upgraded my tunnel node to NB 1394 and the 'ETX 0.00' are no longer shown, but
all the other nodes in my local AREDN network still show them. :-|
So, the recent NBs mask the issue.

In summary, since I cannot fix this issue, I would rather not have this tunnel link.

Chuck

Fri, 03/20/2020 - 10:11

(Reply to #9) #10

nc8q

No dupes in host or service name, but

No dupes in hosts or services names in the 400+ tunneled nodes list, but 'services.local.mesh ETX 0.00' continues.
Also continues in the local mesh network after I disable the tunnel.
Seems to 'infect' my tunnel node running NB 1394.
Issue goes away in the local mesh network after I reboot my formerly tunneled node.
Infection is in RAM I guess.
Resolving this issue is not within my capacity.
I will just not tunnel with those that have the infection.

Chuck

Thu, 03/19/2020 - 20:11

#11

w6bi

Node updates

Chuck, if you can ferret out the exact hostnames of the offending nodes, send them to me. If they're running really old code I'll put out a nagmail on the SoCal mailing list shaming the owners.

Orv W6BI

Fri, 03/20/2020 - 11:54

#12

We1btv

Nodes

looking to, and refreshing the node list on my nodes I see different nodes and services with a 0.00 LQ. On the nodes there are no services running and no duplicate ip adresses found. After a reboot it al starts over, again with different nodes and services.
The software is the latest version, found in the list here on the website.
The why, when and how this happens is not clear to me. The nodes have been running for a long time, years, without this problem.

To solve this problem, I don’t know how but if I can I would help. However, threatning with a “blame and shame” culture or sending e-mails with the text “ the zombies win” do not do any good. Just let me know what to do to tackle this problem.

Ruud, we1btv / pe1btv

Amateur Radio Emergency Data Network

Menu SF

You are here

Strange 0.00 ETX entry in Remote Nodes List

Amateur Radio Emergency Data Network

Search form

Menu SF

You are here

Strange 0.00 ETX entry in Remote Nodes List