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 255.0.0.0.
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.
Thanks,
Keith - AI6BX
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 255.0.0.0.
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.
Thanks,
Keith - AI6BX
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 (0.0.0.0/0)
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)) {
switch_gateway();
}
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...
Joe AE6XE