<div dir="ltr"><div>W/r/t to situations where a gateway node undergoes an uncommanded reboot, e.g. power fails briefly, is there a preferred approach for ensuring all repeater nodes w/in that mesh have their NAT states refreshed as needed, when SmartGateway is in use?<br>
<br></div><div>For example, if the repeater nodes detect their selected gateway node rebooting (i.e. becoming unavailable for a few minutes), or even a new gateway node coming online, should they restart their local instance if olsrd in consequence? <br>
<br></div><div>Or, would the best approach perhaps be to upgrade to olsrd 0.6.6, using the same config? I do see these entries in Changelog that might be useful:<br><pre> kernel_route: olsr_os_inetgw_tunnel_route can now take the table
gateway: let the gateway code determine the tunnel name
gateway: remove the worst gateway before adding new one
gateway: add SmartGatewayUseCount configuration parameter
gateway: use SmartGatewayUseCount setting the the gateway lists
gateway: add SmartGatewayEgressInterfaces configuration parameter
gateway: add SmartGatewayMarkOffset{Egress,Tunnels} configuration
parameters
gateway: add SmartGatewayPolicyRoutingScript configuration parameter
gateway: initialise a set of fixed tunnel names in/for multi-gateway mode
gateway: initialise the egress interface names in/for multi-gateway mode
gateway: use fixed tunnel names in/for multi-gateway mode
gateway: setup and clear table specific default routes in/for
multi-gateway mode
gateway: setup/cleanup multi-gateway mode during startup/shutdown of olsrd
gateway: introduce and use MULTI_GW_MODE define
gateway: enable multi-gateway mode
<br></pre></div><div>Besides that, I have now deployed this param to all nodes, and disabled dyn_gw_plain plugin. However, it looks like a few repeater nodes (not all, mysteriously) still see their route to the WAN, beyond the gateway node, break when the gateway node reboots.<br>
<br>LoadPlugin "olsrd_dyn_gw.so.0.5"<br>{<br> PlParam "HNA" "0.0.0.0 0.0.0.0"<br>}<br><br><br></div><div><br> </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 24, 2014 at 2:55 PM, Teco Boot <span dir="ltr"><<a href="mailto:teco@inf-net.nl" target="_blank">teco@inf-net.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Is *the traffic* from same connection?<div>If so, the NAT state is gone after a reboot and connection shall be restarted. Smart gateway cannot fix all problems.</div>
<div><br></div><div>Teco</div><div><br></div><div> <br><div><div>Op 24 mrt. 2014, om 19:14 heeft Ben West <<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>> het volgende geschreven:</div><div>
<div>
<br><blockquote type="cite"><div dir="ltr">Ferry pointed this out off-list. I've since removed dyn_gw_plain on the nodes where I was testing, and am trying to see if the problem can be repeated.<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">
On Mon, Mar 24, 2014 at 1:11 PM, Teco Boot <span dir="ltr"><<a href="mailto:teco@inf-net.nl" target="_blank">teco@inf-net.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">On original posting: why using both dyn_gw and dyn_gw_plain?<div><br></div><div>Teco<div><div><br></div><div><br><div><div>Op 24 mrt. 2014, om 02:39 heeft Ben West <<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>> het volgende geschreven:</div>
<br><blockquote type="cite"><div><div><div dir="ltr"><div>I have seen sporadic instances of certain repeater nodes' (not all, generally a small subset of all repeater nodes in a given mesh), break their route through the gateway node if the gateway node reboots while the repeater does not.<br>
<br></div>That is, the gateway node reboots, and the affected repeater node thereafter appears to correctly re-establish its route thru the gateway, but the gateway doesn't actually route the repeater's traffic. From the affected node, I can ping the gateway's mesh IP and also the gateway's WAN IP, but I can't ping anything beyond the gateway node's WAN interface.<br clear="all">
<div><div><br></div><div>Restarting olsrd on the repeater node seems to resolve this problem consistently.<br><br></div><div>This is occurring on nodes running OpenWRT AA r39154 and OLSRd v6.5-4, using SmartGateway. I'm quoting my /etc/config/olsrd below, used on all notes alike.<br>
<br></div><div>Has anyone else observed a similar problem? Browsing the changelog at <a href="http://olsr.org/git/" target="_blank">http://olsr.org/git/</a> since v6.5-4 doesn't show any mention of explicit SmartGateway bugfixes, just additional features.<br>
</div><div><br>-----<br>config olsrd<br> # uncomment the following line to use a custom config file instead:<br> #option config_file '/etc/olsrd.conf'<br><br> option 'IpVersion' '4'<br> option 'LinkQualityLevel' '2'<br>
option 'LinkQualityAlgorithm' 'etx_ffeth'<br> option 'SmartGateway' 'yes'<br> option 'Pollrate' '0.1'<br> option 'TcRedundancy' '2'<br> option 'MprCoverage' '5'<br>
<br>config 'LoadPlugin'<br> option 'library' 'olsrd_arprefresh.so.0.1'<br><br>config 'LoadPlugin'<br> option 'library' 'olsrd_dyn_gw.so.0.5'<br><br>config 'LoadPlugin'<br>
option 'library' 'olsrd_dyn_gw_plain.so.0.4'<br><br>config 'LoadPlugin'<br> option 'library' 'olsrd_nameservice.so.0.3'<br> #option 'resolv_file' '/tmp/resolv.conf.auto'<br>
option 'sighup_pid_file' '/var/run/dnsmasq.pid'<br> option 'suffix' '.mesh'<br><br>config 'LoadPlugin'<br> option 'library' 'olsrd_txtinfo.so.0.1'<br> option 'accept' '0.0.0.0'<br>
<br>config 'Interface'<br> list 'interface' 'mesh'<br> option 'Ip4Broadcast' '255.255.255.255'<br> option 'Mode' 'mesh' <br></div><div>#<br><br clear="all">
<br>-- <br>Ben West<div><a href="http://gowasabi.net/" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br><a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a><br>
</div>
</div></div></div></div></div><div>
-- <br>Olsr-users mailing list<br><a href="mailto:Olsr-users@lists.olsr.org" target="_blank">Olsr-users@lists.olsr.org</a><br><a href="https://lists.olsr.org/mailman/listinfo/olsr-users" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-users</a></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>Ben West<div><a href="http://gowasabi.net/" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>
<a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a><br></div>
</div>
</blockquote></div></div></div><br></div></div></blockquote></div><br><br clear="all"><br>-- <br>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>
<a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a><br></div>
</div></div>