You are here

WAN settings

3 posts / 0 new
Last post
WAN settings
As more WAN Gateways are showing up on the network I am seeing situations where connected devices are failing due to paths that are of equal link distance throwing off UDP traffic. I don't think setting up extended port forwarding tables is going to work in solving this as the UDP ports don't behave as the TCP ports where I ahve been successful with forwards in the past. 

I have tried with playing with LinkQualityMult and Willingess settings in the OLSR files without luck, I think because I am crossing several node hops. Alas, looking at WAN settings in the set up page, I thought of setting this to static instead of dhcp. I am thinking the IP would become the WAN IP of my gateway node and the gateway should be the WAN IP of the current gateway node when set to DHCP. As I am working on the WAN side, I am guessing my netmask would be 

Has anyone played with this and proven to work or not? I would like to get some opinion or other ideas before I go mess with this setting at a node I cannot easily get to.


Keith - AI6BX
What is your WAN connected to
What is your WAN connected to now ? Are you connecting locally to your internet provider ?
AE6XE's picture
AI6BX and I worked through
AI6BX and I worked through some settings on this issue.  We've found that the OLSR NatThreshold parameter is solving the problem of a node picking a different mesh gateway, flipping back, and so on.  This parameter makes the bar higher (the setting says how high) before a node will pick another mesh gateway.   Basically, setting this value, must be between 0.1 and 1, the calulation then takes the cost or ETX to the current mesh gateway and multiplies it by this factor.  This lowers the cost to select the current gateway.  Another gateway must have an even lower cost before it would be selected.   

Although, caution is in order, let's say the link is completely out to the desired gateway, e.g. rebooted a node in the middle.   If the fall back gateway is selected, if this NatThreshold value is too low (very high bar to select another mesh gateway), then you might not get back to the desired gateway.

The README in the olsr distribution:
The NatThreshold option was introduced by Sven Ola to suppress a very annoying
problem with OLSRd, switching default gateways. If a router is located between
two Internet gateways with similar path costs the default route (
will constantly switch between the two gateways due to normal fluctuations of
the link metrics. Whenever OLSRd decides that the other NAT gateway is
"better", then switching to this new gateway will result in termination of all
connected sessions (TCP and HTTP).
The user experience will be rather painful and users will experience hanging
SSH and HTTP sessions (or anything using TCP).

NatThreshold tries to help by introducing a hysteresis factor for
choosing the route to the default gateway. Only if the new gateway has
a lower cost than the current gateways path cost multiplied by
NatThreshold the node will switch the gateway.
In short:

  if (cost(new_gateway) < cost(current_gw)*NatThreshold)) {

Practical experience shows that this leads to much better quality of default
gateway selection, even if (in theory) a small NatThreshold together with
Fisheye can lead to  persistent routing loops.
Please note that even with NatThreshold enabled, some users will still
experience gateway switching. However, most users will not.

this recommendation suggests we need to configure this setting in AREDN.  The big question is, what value...


Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer