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

Sun Aug 4 16:02:44 UTC 2013

On Sat 03 Aug 2013 10:08:56 PM EDT, Will Hawkins wrote:
> Ben,
>
> Thank you for sending this out to the list. Keep us updated on your
> progress. We will work through your recommendations on our end and see
> what comes of it. Thanks again!
>
> Will
>
> On 08/03/2013 08:38 PM, Ben West wrote:
>> 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
>> <mailto: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 <mailto: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 <mailto:ben at gowasabi.net>
>>     314-246-9434 <tel:314-246-9434>
>>
>>
>>
>>
>> --
>> Ben West
>> http://gowasabi.net
>> ben at gowasabi.net <mailto:ben at gowasabi.net>
>> 314-246-9434 <tel:314-246-9434>
>>
>>
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev
>

Would we be able to verify the MTU problem by doing packet captures 
along the route from a repeater to a gateway, and checking the MTU of 
packets that get through versus those that get dropped?

--
Dan Staples

Open Technology Institute
https://commotionwireless.net
OpenPGP key: http://disman.tl/pgp.asc
Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9