Hi All,<br><br>I'm emailing here in follow-up to a recent thread on commotion-discuss about repeater nodes not reliably having their internet-bound traffic routed.<br><br>In particular, I was seeing my own repeater nodes, both 1-hop way and especially 2-hops away, apparently losing their connection to the Internet once the local OLSRd instance had inserted its tnl_* interface (i.e. a few minutes after power up). I'm highlighting the instance of a node 2-hops away, since in practice that can be difficult to replicate.<br>
<br>Below is the readme about the SmartGateway feature. Do please note in particular the recommendation to add an iptables rules to the gateway node, clamping all packets leaving the mesh to the same MTU as what is used by the OLSRd SmartGateway tunnels.<br>
<br><a href="http://svn.dd-wrt.com/browser/src/router/olsrd/README-Olsr-Extensions" target="_blank">http://svn.dd-wrt.com/browser/src/router/olsrd/README-Olsr-Extensions</a><br><br>This seemed to resonate with a sporadic problem I'd been having with
repeater nodes occasionally not seeing their Internet-bound traffic
correctly routed, despite all routing tables appearing valid. These repeater nodes restored their Internet connection when I enabled the 'mtu_fix'
option on their local firewall. But not consistently so, making the problem very challenging to resolve.<br><br>So, following the advice from the readme, I added this to /etc/firewall.user on my gateway node (eth0 is its wired uplink):<br>
<br>iptables -A FORWARD -o eth0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1480<br><br>On the gateway node with wired WAN and LAN ports, in addition to the mesh interface, I set these firewall zones in /etc/config/firewall:<br>
<br><div style="margin-left:40px">config zone<br> option name 'mesh'<br> option network 'mesh'<br> option input 'ACCEPT'<br> option output 'ACCEPT'<br> option forward 'ACCEPT'<br>
option 'masq' '1'<br><br>config zone<br> option name 'wan'<br> option output 'ACCEPT'<br> option masq '1'<br> option input 'DROP'<br> option forward 'ACCEPT'<br>
<br>config zone<br> option input 'ACCEPT'<br> option output 'ACCEPT'<br> option forward 'ACCEPT'<br> option name 'lan'<br> option network 'lan'<br><br>config forwarding<br>
option src 'mesh'<br> option dest 'wan'<br><br>config forwarding<br> option src 'lan'<br> option dest 'wan'<br><br>config 'forwarding' <br> option 'src' 'mesh' <br>
option 'dest' 'mesh'<br></div><br>Next, on repeater nodes with only one LAN port (counter-intuitively labeled 'wan'), these are the firewall zones:<br><br><div style="margin-left:40px">config 'zone'<br>
option 'name' 'mesh'<br> option 'input' 'ACCEPT'<br> option 'output' 'ACCEPT'<br> option 'forward' 'ACCEPT'<br><br>config zone<br> option name wan<br>
option input ACCEPT<br> option output ACCEPT <br> option forward ACCEPT<br> option masq 1 <br><br>config 'forwarding'<br> option 'src' 'wan'<br> option 'dest' 'mesh'<br>
<br>config 'forwarding' <br> option 'src' 'mesh' <br> option 'dest' 'mesh'<br></div><br>In particular, note how the 'masq' option is enabled on the zone 'mesh' only for the gateway node, but not on the repeater nodes. Likewise, 'masq' is enabled on the zone corresponding to the local LAN port of the repeater nodes, but not on the LAN port of the gateway node. For Commotion-OpenWRT, the firewall zones of the LAN ports would be equivalent to those of the APs of each node.<br>
<br>This configuration described above appears to be what works for using the SmartGateway feature with OLSRd v0.6.5.4-commotion-0.1-1.<br><br>I'm trying to review the firewall rules that commotiond is generating for gateway and repeater nodes, to see if they follow. However, I'm posting to the listserv now in case someone else happens to see an oversight in how Commotion-OpenWRT is deploying OLSRd and firewall config.<br>
<br><div class="gmail_quote">On Thu, Aug 1, 2013 at 1:38 PM, Ben West <span dir="ltr"><<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Hi All,<br><br>I can confirm having encountered similar issues
specifically repeater nodes not correctly masq'ing AP traffic to the
Internet, while gateway nodes do. My own problems were encountered
running both private APs and coovachilli APs (as opposed to nodogsplash)
on nodes running the WasabiNet firmware, not Commotion-OpenWRT. However
the firewall config is quite similar.<br>
<br>So, on repeater nodes I have the 'masq' option enabled for zones
mesh, ap1, and ap2 (i.e. public and private APs). On gateway nodes, it
seems that I need to have 'masq' disabled for zones ap1 and ap2.<br><br></div><div class="gmail_quote"><div>On Wed, Jul 31, 2013 at 5:18 PM, Ryan Gerety <span dir="ltr"><<a href="mailto:gerety@opentechinstitute.org" target="_blank">gerety@opentechinstitute.org</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>After a further chat with Preston, this seems like it *might* be the same problem I encountered at the Hackerspace in Tunis. When using the AP of the gateway node the client can access the internet and when on another mesh node (say via ssh) you can access the internet, however, when you are on the AP of another node you cannot access the internet.<br>
<br>
I had sent this to the tech list about two weeks ago, and in the office Seamus and Griffin thought it might be a zone issue. Seamus and Griffin did you discover what the problem actually was? Were you able to replicate the problem?<br>
<br>
Best,<br>
Ryan</div><div><div><br>
<br>
<snip><br>
</div></div></blockquote></div><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></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>