After installing the current nightly build 1580, and at least the one before, you may notice that tunnel links will have changed from showing a "1.0" cost to now a "0.1" cost same as a dtdlink. Here's the background, sorry somewhat lenghty...
As you may have seen in the forums or other postings, on some of the large mesh networks, particularly in Southern CA, there are symptoms showing up referred to as "OLSR storms". For a few minutes a given node will show 500+ node mesh network and routing becomes disrupted for a few minutes and the node only shows routing information dropping down to 10s of nodes on the network. Consequently, communications is lost to most of the devices across the network. There has been some corelation observed with these symptoms when multiple path tunnel links are connecting up mesh islands. We have no way to test a hypothesis of a fix, except to push out for use on this large scale.
By adding an option to OLSR to give the tunnel the same configuration settings as DtDLink, both generally are links over Ethernet, this changes OLSR behavior to not forward OLSR messages back the same way they were received. This causes the 'cost' to be '0.1'. On a wireless link with 802.11n in use, it would be necessary to retransmit the OLSR messages in duplication over the RF channel so that all hidden nodes will see the message. With Ethernet, there are no hidden nodes and we want to cut down on the forwarding of messages. A packet capture has observed a circular pattern of messages being forwarded in the storm, but it is still a mystery how this is happening. By reducing this unnecessary forwarding of messages on tunnels, the question is if it will make a difference with these olsr storms.
Consequently, if you are running a tunnel, please help out to upgrade to the nightly build and contribute to testing this hypothesis.
Please post here of any issues with the change from 1.0 to 0.1 cost of a tunnel link. Generally, there are not redundant paths to choose from, and thus routing paths would not change due to this cost difference. (If there is a redundant path, the tunnel wouldn't generally be needed to begin with.)
Check to confirm that both directions of the tunnel are using the same cost value in mesh status on both nodes on each side. It may be problematic if they are not: if the return path of a network connection is different, due to different cost values based on direction, then traffic may not be able to get back to establish the connection -- firewall rules allow return traffic have to see the initiating traffic first. Please report any impact good or bad to help obtain the information needed to reach a decision and determine what needs to be in 3.20.3.1 point release.
Joe AE6XE
As you may have seen in the forums or other postings, on some of the large mesh networks, particularly in Southern CA, there are symptoms showing up referred to as "OLSR storms". For a few minutes a given node will show 500+ node mesh network and routing becomes disrupted for a few minutes and the node only shows routing information dropping down to 10s of nodes on the network. Consequently, communications is lost to most of the devices across the network. There has been some corelation observed with these symptoms when multiple path tunnel links are connecting up mesh islands. We have no way to test a hypothesis of a fix, except to push out for use on this large scale.
By adding an option to OLSR to give the tunnel the same configuration settings as DtDLink, both generally are links over Ethernet, this changes OLSR behavior to not forward OLSR messages back the same way they were received. This causes the 'cost' to be '0.1'. On a wireless link with 802.11n in use, it would be necessary to retransmit the OLSR messages in duplication over the RF channel so that all hidden nodes will see the message. With Ethernet, there are no hidden nodes and we want to cut down on the forwarding of messages. A packet capture has observed a circular pattern of messages being forwarded in the storm, but it is still a mystery how this is happening. By reducing this unnecessary forwarding of messages on tunnels, the question is if it will make a difference with these olsr storms.
Consequently, if you are running a tunnel, please help out to upgrade to the nightly build and contribute to testing this hypothesis.
Please post here of any issues with the change from 1.0 to 0.1 cost of a tunnel link. Generally, there are not redundant paths to choose from, and thus routing paths would not change due to this cost difference. (If there is a redundant path, the tunnel wouldn't generally be needed to begin with.)
Check to confirm that both directions of the tunnel are using the same cost value in mesh status on both nodes on each side. It may be problematic if they are not: if the return path of a network connection is different, due to different cost values based on direction, then traffic may not be able to get back to establish the connection -- firewall rules allow return traffic have to see the initiating traffic first. Please report any impact good or bad to help obtain the information needed to reach a decision and determine what needs to be in 3.20.3.1 point release.
Joe AE6XE
Joe
For me, in order to try this with some of the tunnel nodes I have, I would have to lose remote access to update the firmware (disable tunnels).
However, I was able to paste insert your addition at line 147:
push @file, qq( Mode \"ether\"\n);
into:
And then with a node reboot:
had the additions.
This could be a way for others to try this without having to lose tunnel access.