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

Tue Aug 6 18:54:19 UTC 2013

Hey All,

Thanks to Preston I have a debug info file from on of the affected
routers on our networks. I am heads down until next week, and as such
wont be able to track down the bug. If anyone needs the debug info file
to explore it, please let me know and I will send it to you.

s2e

On 08/04/2013 12:03 PM, Dan Staples wrote:
> 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 size of
> packets that get through versus those that get dropped?
> 