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??
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
I've performed over the air updates with nodes four hops away.
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..
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.
LQ
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.
NLQ
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.
ETX
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.
TxMbps
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)
"(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)
"(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".
(wan)
"(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.
Joe,
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
echo /all | nc 127.0.0.1 2006 | grep 0.0.0.0
This is currently in the list (along with many others):
0.0.0.0/0 10.228.31.50 <- 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 AE6XE
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.
Conrad, the node in question is a linksys :) .