You are here

Upgrade issues

12 posts / 0 new
Last post
Upgrade issues
I have found that attempting an over-the-air upgrade using the AREDN UI with an ETX much over 2 inevitably fails. That is, the upload starts but stalls almost immediately and never completes.  This would seem to be a timing issue.  Is there anyway around this? Like ftp to the node and then update, or??
kg9dw's picture
In my mesh, the etx is more a
In my mesh, the etx is more a measure of the number of hops. The LQ tells me how well the link is performing. Do you have RF links that aren't solid?

I've performed over the air updates with nodes four hops away.
The node in question is two

The node in question is two hops away and has an average ETX around 2.8.  I successfully upgraded three other nodes over two hops. But those all had an ETX under 2.  

IIRC, ETX us a measure of path quality and refers to the expected number of re-transmissions required to successfully transmit a packet. An ETX of one (like in a dtdlink) means no expected re-transmissions.   I think re-transmissions, and therefore delayed TCP ACKs, may be the cause of this problem..

K5DLQ's picture
i think the web server also
i think the web server also has a 30sec timeout as well (IIRC).
I have one node on a very problematic link (20-40% LQ) that I can't update OTA either.  I need to move that node for a better path.
K6AH's picture
Browser timout
I've experienced the same issue upgrading nodes several hops away.  Everything is going along fine, but slowly, and suddenly at 60-70% progress it dies.  I'm convinced it's the browser timeout that kills it.  
AE6XE's picture
mesh status help information in a future release--see ETX


Link Quality (LQ) is the % of packets received from the Neighbor in the OLSR mesh routing protocol from the perspective of the Local Host. OLSR packets are exchanging routing, advertised services, and other information and include a sequence number with each packet to determine missing packets to characterize the quality of the link.


Neighbor Link Quality (NLQ) is the % of packets the Neighbor received from the perspective of the Local Host in the OLSR mesh routing protocol. The NLQ is the LQ from the Neighbor's perspective.


Expected Transmissions (ETX) is a Bernoulli statistic of how many packets must be transmitted to successfully receive the round trip acknowledgement between Neighbor nodes and is calculated with this formula: ETX = 1/(LQ*NLQ). Between multiple hop nodes, this is calculated by adding up the ETX for each single hop. "1" is a perfect RF link between Neighbors. A DtDLink is fixed at ETX="0.1" for packets over a cat5 cable. OLSR on a Mesh Node selects the Neighbor to send traffic to based on the lowest cost ETX path towards the final destination Node.

ETX should be interpreted with care. From a quality perspective, the ETX for Remote Nodes is not an end-to-end metric in the same way as adjacent neighbors. For example, 2 nodes that are 5 hops apart with zero packet loss between them is characterized with an ETX=5. A single hop with ETX=5 (LQ and NLQ is ~45%) will stream poor quality video, if usable at all, given the packet loss. A 5 hop route between nodes with ETX=5 will deliver smooth streaming quality video.


Transmitted Mbps (TxMbps) is the measured transmitted throughput, at the packet level, after accounting for packet loss. The 802.11 driver bases the selection, to each Neighbor, of modulation scheme and number of antennas (multiple polarized spatial streams of data) on the combination that achieves the highest throughput. If no traffic is being sent to this Neighbor, then the value may be '0' until data is available to measure and determine the optimal settings. For further details: Rate Control Algorithm


"(wan)" next to a Mesh Node indicates the node is an Advertised Gateway. Typically this is to the internet, but may also be an isolated network.


"(dtd)" next to a Mesh Node indicates the path to a Neighbor is a cat5 cable. The Neighbor may be listed twice if both an RF and DtDLink path exists. The DtDLink path is always assigned an ETX of "0.1".

Thanks Joe.  Your post should
Thanks Joe.  Your post should probably be made into a documentation and a sticky topic on this forum.
I also believe a lot of this
I also believe a lot of this is in the ONBOARD HELP file as well and as such is available to the operator every time they log in to a node.
N2MH's picture


"(wan)" next to a Mesh Node indicates the node is an Advertised Gateway. Typically this is to the internet, but may also be an isolated network.


Would this also include tunnel clients/servers? I'm seeing wan next to some of my nodes but the Mesh Gateway box is not checked in their configuration.

73, Mark, N2MH

AE6XE's picture
Mark,    the bogus (wan) in
Mark,    the bogus (wan) in the mesh status appears to be from the node NJ2RC-FieldTun4 (which I can see has no wan address shown under node status).   However, olsr still shows this is an adverted gateway.   This command on any non-gateway node will tell you all the advertised gateways:

echo /all | nc 2006 | grep

This is currently in the list (along with many others):  <- hostname is NJ2RC-RieldTun4

I'd suggest powering it down for 15 min, then powering it back up to see if the issue is resolved.   Was it a gateway and changed recently?   This might be OLSR defect that does not un-cache data correctly.   Issue occurs with hostname change.  leaving a node powered off for a period of time will cause any cached info to be cleaned up across the mesh.   

In regards to tunnel interfaces, the firmware doesn't uniquely identify and pass around in the OLSR information that an address is a tunnel.  With dtdlink, there is actually a hostname under the hood of "dtdlink.<node name>.local.mesh".  We know it is dtd.  When I originally wrote this code, I was putting (tun) next to devices believed to be tunnel links.  However, the code was removed when discovered that it may be wrong in some cases--guessing.  Maybe at a later time, we could pass along information in OLSR to uniquely identify these links to show where the tunnel connections are--this would be useful.

Joe: did you look at OLSRD
Joe: did you look at OLSRD status (port 1978) to check if it was indeed not configured as a meshgw? (the dynamic gateway module should not be loaded)

BTW: the node might be in NAT mode or might have the WAN disabled in which case it wouldn't have a WAN address but could be still running as a meshgw from a gui standpoint its an extremely rare deployment (not sure anyone has ever done it)  but the checkboxes can be ticked in that manner.

A support data file from said node BEFORE it reboots could be useful as well to help determine if this is a bug or not based on how that node is configured.

To my knowledge there is no issue with the expiring of default gateways.

Also might be better to take this to a new thread as its getting off the original topic as we go down a debug path.
AE6XE's picture
Conrad,  the node is question

Conrad,  the node in question is a linksys :) .   

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer