[Commotion-dev] Setting masq & MTU values correctly with OLSRd SmartGateway

Sun Aug 4 00:38:38 UTC 2013

Hi All,

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.

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.

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.

http://svn.dd-wrt.com/browser/src/router/olsrd/README-Olsr-Extensions

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.

So, following the advice from the readme, I added this to
/etc/firewall.user on my gateway node (eth0 is its wired uplink):

iptables -A FORWARD -o eth0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS
--set-mss 1480

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:

config zone
    option name 'mesh'
    option network 'mesh'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    option 'masq' '1'

config zone
    option name 'wan'
    option output 'ACCEPT'
    option masq '1'
    option input 'DROP'
    option forward 'ACCEPT'

config zone
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    option name 'lan'
    option network 'lan'

config forwarding
    option src 'mesh'
    option dest 'wan'

config forwarding
    option src 'lan'
    option dest 'wan'

config 'forwarding'
    option 'src' 'mesh'
    option 'dest' 'mesh'

Next, on repeater nodes with only one LAN port (counter-intuitively labeled
'wan'), these are the firewall zones:

config 'zone'
    option 'name' 'mesh'
    option 'input' 'ACCEPT'
    option 'output' 'ACCEPT'
    option 'forward' 'ACCEPT'

config zone
    option name        wan
    option input    ACCEPT
    option output    ACCEPT
    option forward    ACCEPT
    option masq        1

config 'forwarding'
    option 'src' 'wan'
    option 'dest' 'mesh'

config 'forwarding'
        option 'src' 'mesh'
        option 'dest' 'mesh'

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.

This configuration described above appears to be what works for using the
SmartGateway feature with OLSRd v0.6.5.4-commotion-0.1-1.

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.

On Thu, Aug 1, 2013 at 1:38 PM, Ben West <ben at gowasabi.net> wrote:

> Hi All,
>
> 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.
>
> 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.
>
> On Wed, Jul 31, 2013 at 5:18 PM, Ryan Gerety <gerety at opentechinstitute.org
> > wrote:
>
>> 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.
>>
>> 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?
>>
>> Best,
>> Ryan
>>
>>
>> <snip>
>>
>
>
>
> --
> Ben West
> http://gowasabi.net
> ben at gowasabi.net
> 314-246-9434
>

-- 
Ben West
http://gowasabi.net
ben at gowasabi.net
314-246-9434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20130803/8610480d/attachment.html>