<div dir="ltr"><div><br></div><div>To distill the important points about my suspicions of mismatched MTUs:<br><br></div><div>1. The OLSRd readme for SmartGateway specifically recommends clamping MTU=1480 for all packets leaving the mesh on a gateway node, to align with the MTU used by tunnels b/w nodes that SmartGateway creates.<br>

<br></div><div>2. Before adding the iptables rule for #1, I did see certain repeater nodes lose Internet connectivity (aka pings to the outside fail) <i>immediately after</i> their local OLSRd instance added the tnl_* tunnel to the gateway node.<br>

<br></div><div>3. Likewise, trail and error with the 'mtu_fix' option on the firewalls of gateway and repeater nodes did appear effective in restoring repeater nodes' route to the outside, but not in any discernibly consistent fashion.  mtu_fix = "enable MSS clamping for <em>outgoing</em> zone traffic."  So, mtu_fix seems to imperfectly or incompletely perform the same function as the iptables rule in #1.  I've since disabled mtu_fix on all mesh nodes affected, to avoid throughput loss from any unnecessary MTU clamping.<br>

<br></div><div>4. Finally, the 'masq' option appears necessary for the mesh and WAN firewall zones on the gateway node, and likewise for the AP/LAN zones on repeater nodes.  It should not be enabled on the AP/LAN zones on the gateway node, nor on the mesh zone for repeater nodes.  (This last item could be in error.  Theoretically, one would expect masq to be required for all zones.)<br>

<br></div><div>All of these details do suggest that a node needing to switch from gateway to repeater role on-the-fly, i.e. when a wired uplink fails, will likely need to reboot.<br></div><div><br></div></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Sun, Aug 4, 2013 at 12:27 PM, Seamus Tuohy <span dir="ltr"><<a href="mailto:s2e@opentechinstitute.org" target="_blank">s2e@opentechinstitute.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>Yea, I think with the info you have its plus the debugging info on the networks we have seen (if those who have seen this could send that) we can create a close approximation and monitor it closely.<br>
<br><br><div class="gmail_quote">Dan Staples <<a href="mailto:danstaples@opentechinstitute.org" target="_blank">danstaples@opentechinstitute.org</a>> wrote:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<pre><div><div class="h5">On Sun 04 Aug 2013 12:25:35 PM EDT, Ben West wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #729fcf;padding-left:1ex"><div><div class="h5">

It unfortunately wouldn't be possible for me to revert these node back<br>to known bag configuration and do packet capture, since the nodes are<br>under active use by folks other than me (their patience can be finite<br>

;).  Usually, my encounters with this issue spring from complaints<br>about nodes losing their Internet route and needing recovery.  So, the<br>testing results I would be able to share for this instance are going<br>to be limited to largely empirical results.<br>

<br><br>On Sun, Aug 4, 2013 at 11:02 AM, Dan Staples<br><<a href="mailto:danstaples@opentechinstitute.org" target="_blank">danstaples@opentechinstitute.org</a><br><mailto:<a href="mailto:danstaples@opentechinstitute.org" target="_blank">danstaples@opentechinstitute.org</a>>> wrote:<br>

<br>On Sat 03 Aug 2013 10:08:56 PM EDT, Will Hawkins wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8e x;border-left:1px solid #ad7fa8;padding-left:1ex">Ben,<br><br>Thank you for sending this out to the list. Keep us updated on your<br>

progress. We will work through your recommendations on our end<br></blockquote>and see<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">what comes of it. Thanks again!<br>

<br>Will<br><br>On 08/03/2013 08:38 PM, Ben West wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">Hi All,<br><br>I'm emailing here in follow-up to a recent thread on<br>

</blockquote></blockquote>commotion-discuss<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

about repeater nodes not reliably having their
internet-bound<br></blockquote></blockquote>traffic<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

routed.<br><br>In particular, I was seeing my own repeater nodes, both 1-hop<br></blockquote></blockquote>way and<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">especially 2-hops away, apparently losing their connection to the<br>Internet once the local OLSRd instance had inserted its tnl_*<br>

</blockquote></blockquote>interface<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

(i.e. a few minutes after power up).  I'm highlighting the<br></blockquote></blockquote>instance of a<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">node 2-hops away, since in practice that can be difficult to<br></blockquote></blockquote>replicate.<br><br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">Below is the readme about the SmartGateway feature.  Do please<br></blockquote></blockquote>note in<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">particular the recommendation to add an iptables rules to the<br></blockquote></blockquote>gateway<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">node, clamping all packets leaving the mesh to the same MTU as<br></blockquote></blockquote>what is<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">used by the OLSRd SmartGateway tunnels.</blockquote><br><br></blockquote><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><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

This seemed to resonate with a sporadic problem I'd been having<br></blockquote></blockquote>with<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

repeater nodes occasionally not seeing their Internet-bound traffic<br>correctly routed, despite all routing tables appearing valid.<br></blockquote></blockquote>These<br><blockquote class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

repeater nodes restored their Internet connection when I<br></blockquote></blockquote>enabled the<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

'mtu_fix' option on their local firewall.  But not consistently so,<br>making the problem very challenging to resolve.<br><br>So, following the advice from the readme, I added this to<br>/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<br></blockquote></blockquote>TCPMSS<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

--set-mss 1480<br><br>On the gateway node with wired WAN and LAN ports, in addition<br></blockquote></blockquote>to the<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">mesh interface, I set these firewall zones in /etc/config/firewall:<br><br>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><br>Next, on repeater nodes with only one LAN port (counter-intuitively<br>labeled 'wan'), these are the firewall zones:<br>

<br>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><br>In particular, note how the 'masq' option is enabled on the<br></blockquote></blockquote>z
 one
'mesh'<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

only for the gateway node, but not on the repeater nodes.<br></blockquote></blockquote>Likewise,<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

'masq' is enabled on the zone corresponding to the local LAN<br></blockquote></blockquote>port of the<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">repeater nodes, but not on the LAN port of the gateway no
 de. 
For<br>Commotion-OpenWRT, the firewall zones of the LAN ports would be<br>equivalent to those of the APs of each node.<br><br>This configuration described above appears to be what works for<br></blockquote></blockquote>using<br>

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

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<br></blockquote></blockquote>generating<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">for gateway and repeater nodes, to see if they follow.<br></blockquote></blockquote></div></div>However, I'm<
 br
/><div><div class="h5"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

posting to the listserv now in case someone else happens to see an<br>oversight in how Commotion-OpenWRT is deploying OLSRd and<br></blockquote></blockquote>firewall config.<br><br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">On Thu, Aug 1, 2013 at 1:38 PM, Ben West <<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>

<</blockquote></blockquote>mailto:<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>><br><<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote">mailto:<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a> <mailto:<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>>>> wrote:<br><br>Hi All,<br>

<br>I can confirm having encountered similar issues specifically<br>repeater nodes not correctly masq'ing AP traffic to the<br></blockquote></blockquote>Internet,<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">while gateway nodes do.  My own problems were encountered<br></blockquote></blockquote>running<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">both private APs and coovachilli APs (as opposed to<br></blockquote></blockquote>nodogsplash) on<br><u></u><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

nodes running the WasabiNet firmware, not<br></blockquote></div></div></blockquote><div><div class="h5">Commotion-OpenWRT. However<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">the firewall config is quite similar.<br><br>So, on repeater nodes I have the 'masq' option enabled for<br>

</blockquote></blockquote>zones<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

mesh, ap1, and ap2 (i.e. public and pri
 vate
APs).  On<br></blockquote></blockquote>gateway nodes,<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

it seems that I need to have 'masq' disabled for zones ap1<br></blockquote></blockquote>and ap2.<br><br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">On Wed, Jul 31, 2013 at 5:18 PM, Ryan Gerety<br><<a href="mailto:gerety@opentechinstitute.org" target="_blank">gerety@opentechinstitute.org</a><br>

<</blockquote></blockquote>mailto:<a href="mailto:gerety@opentechinstitute.org" target="_blank">gerety@opentechinstitute.org</a>><br><mailto:<a href="mailto:gerety@opentechinstitute.org" target="_blank">gerety@opentechinstitute.org</a><br>

<mailto:<a href="mailto:gerety@opentechinstitute.org" target="_blank">gerety@opentechinstitute.org</a>>>><br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">wrote:<br><br>After a further chat with Preston, this seems like it<br></blockquote></blockquote>*might* be<br>

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

the same problem I encountered at the Hackerspace in Tunis.<br>When using the AP of the gateway node the client can<br></blockquote></blockquote>access the<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">internet and when on another mesh node (say via ssh)<br></blockquote></blockquote>you
  can<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

access the internet, however, when you are on the AP of<br></blockquote></blockquote>another<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

node you cannot access the internet.<br><br>I had sent this to the tech list about two weeks ago,<br></blockquote></blockquote>and in the<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">office Seamus and Griffin thoug
 ht it
might be a zone issue.<br>Seamus and Griffin did you discover what the problem<br></blockquote></blockquote>actually<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">was?  Were you able to replicate the problem?<br><br>Best,<br>Ryan<br><br><br><snip><br><br><br><br><br>

--<br>Ben West<br><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a> <mailto:<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>><br>

<</blockquote></blockquote>mailto:<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a> <mailto:<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>>><br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex"><a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a> <tel:314-246-9
 434>
<tel:<a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a><br><</blockquote></blockquote>tel:<a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a>>><br><br>

<br><br><br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

--<br>Ben West<br><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a> <mailto:<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>><br>

<</blockquote></blockquote>mailto:<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a> <mailto:<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>>><br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex"><a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a> <tel:<a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a>> <tel:<a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a><br>

<</blockquote></blockquote>tel:<a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a>>><br><br><br></div></div><blockquote class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

<hr><br>Commotion-dev mailing list<br><a href="mailto:Commotion-dev@lists.chambana.net" target="_blank">Commotion-dev@lists.chambana.net</a><br><</blockquote></blockquote>mailto:<a href="mailto:Commotion-dev@lists.chambana.net" target="_blank">Commotion-dev@lists.chambana.net</a>><br>

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex">

<a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a></blockquote><br><hr><br>Commotion-dev mailing list<br><a href="mailto:Commotion-dev@lists.chambana.net" target="_blank">Commotion-dev@lists.chambana.net</a><br>

<</blockquote><div class="im">mailto:<a href="mailto:Commotion-dev@lists.chambana.net" target="_blank">Commotion-dev@lists.chambana.net</a>><br><blockquote class="gmail_quote"><a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a></blockquote>

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

Dan Staples<br><br>Open Technology Institute<br><a href="https://commotionwireless.net" target="_blank">https://commotionwireless.net</a><br>OpenPGP key: <a href="http://disman.tl/pgp.asc" target="_blank">http://disman.tl/pgp.asc</a><br>

Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9<br><hr><br></div><div class="im">Commotion-dev mailing list<br><a href="mailto:Commotion-dev@lists.chambana.net" target="_blank">Commotion-dev@lists.chambana.net</a><br>

<mailto:<a href="mailto:Commotion-dev@lists.chambana.net" target="_blank">Commotion-dev@lists.chambana.net</a>><br><a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a><br>

<br><br><br><br>--<br>Ben West<br><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a> <mailto:<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></div></pre></blockquote><div class="im"><br>We could try it on our test networks to diagnose the problem, if you <br>think it would lead to useful data. I'm just trying to think of ways we <br>

could test your hypothesis about the MTU issue...<br><br>--<br>Dan Staples<br><br>Open Technology Institute<br><a href="https://commotionwireless.net" target="_blank">https://commotionwireless.net</a><br>OpenPGP key: <a href="http://disman.tl/pgp.asc" target="_blank">http://disman.tl/pgp.asc</a><br>

Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9<br></div><div class="im"><hr><br>Commotion-dev mailing list<br><a href="mailto:Commotion-dev@lists.chambana.net" target="_blank">Commotion-dev@lists.chambana.net</a><br>

<a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a><br><br><br></div></div><span class="HOEnZb"><font color="#888888"><br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.</font></span></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>314-246-9434<br></div>
</div>