[Commotion-dev] Setting masq & MTU values correctly with OLSRd SmartGateway
Preston Rhea
prestonrhea at opentechinstitute.org
Tue Aug 6 20:37:28 UTC 2013
A quick context update to that: I just noticed from looking at the
Zabbix dashboard that the node stopped recording data right at the
time I got kicked off of it. I just sshed in and ran 'ps' to see if
zabbix_agentd was running on the node but it wasn't, so I restarted
it.
So I guess the lesson, which I should have known anyway, is that you
have to manually start the zabbix agent; it won't start on startup. We
should keep this in mind whenever we restart nodes.
On Tue, Aug 6, 2013 at 2:54 PM, Seamus Tuohy <s2e at opentechinstitute.org> wrote:
> 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?
>>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev
>
--
Preston Rhea
Field Analyst, Open Technology Institute
New America Foundation
+1-202-570-9770
Twitter: @prestonrhea
More information about the Commotion-dev
mailing list