Hi Vignesh,<div>I need NAT because node D is constrained to talk only to 192.168.1.2. I therefore masquerade the packets coming in from the mesh to translate their source ip addresses to 192.168.1.2. I think my problem is more to do with congestion of the mesh network due to high bandwidth usage by my application which runs on node A.</div>
<div>Thanks much!</div><div>Arjun.</div><div><br></div><div><br><div class="gmail_quote">On Mon, Feb 13, 2012 at 2:32 AM, Vigneswaran R <span dir="ltr"><<a href="mailto:vignesh@atc.tcs.com">vignesh@atc.tcs.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
On Saturday 11 February 2012 03:38 AM, Arjun wrote:<br>
[...]<div class="im"><br>
<blockquote type="cite">I have to use the NAT iptables rule on Node C, because
Node D (192.168.1.1) can only talk to 192.168.1.2, which is IF2 on
Node C. So packets originating from the OLSR mesh must have their
source ips masqueraded to 192.168.1.2. Now that I think of it,
maybe I can nose around inside the linux box on Node D (which is
actually a commercial toy) and see if I can open it up to connect
to ip addresses other than 192.168.1.2.</blockquote>
<br></div>
I think, NAT can be removed from your setup due to the following
reason,<br>
<br>
1. OLSR machines have route to D (and it's network) via C (because
of HNA)<br>
2. So, the packets originated from OLSR mesh reach C and then
forwarded to D.<br>
-- Here, C does simple IP Forwarding (no NATting)<br>
-- And the forwarded packets will have the source IP unmodified<br>
3. Since D doesn't have route to that source IP, it will send the
reply packets to/via the default gateway (which is C, I believe).<br>
4. When C receives this reply packet, it routes it to the proper
destination in the OLSR mesh.<br>
<br>
<br>
Regards,<br>
Vignesh<div class="im"><br>
<br>
<br>
<blockquote type="cite">
<div>I think the problems I have are most likely due to mobility,
because the toy moves reasonably fast, and leaky UDP streams. I
will shorten the Hello/TC intervals and see if that helps. Do
let me know if any other suggestion comes to mind.</div>
<div>Thanks again!</div>
<div>Arjun.</div>
<div><br>
</div>
<div><br>
<div class="gmail_quote">On Fri, Feb 10, 2012 at 2:46 PM, Markus
Kittenberger <span dir="ltr"><<a href="mailto:Markus.Kittenberger@gmx.at" target="_blank">Markus.Kittenberger@gmx.at</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">afair
smart-gateway does not do anything useful for your setup,.
<div>as its only for hna announcements of <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> (and useful only if u have
multiple nodes announcing this)</div>
<div><br>
</div>
<div>anyways to simplify things, do not use smartgateway,
hna alone is enough!</div>
<div><br>
</div>
<div>and if possible (to simplify more) also remove the NAT
in your testcase, use a static route on your target
towards the mesh inestead,..<br>
<br>
or just try (and verify the amount of packetloss of) an
udp stream to node C, and not the node behind C,.. (so you
can leave away the hna too)</div>
<div><br>
</div>
<div>if this simplified setup works, you have issues with
nat/hna,..</div>
<div>if not, you have problems with mobility (which usually
can causes "some" packetloss, and maybe just too much for
your udp stream)</div>
<div><br>
</div>
<div>
<div class="gmail_quote">
<div>On Fri, Feb 10, 2012 at 7:07 PM, Arjun <span dir="ltr"><<a href="mailto:akarjun@gmail.com" target="_blank">akarjun@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>However, when I move node B out of range from the
gw, i.e. node C, so that it is 2 hops away, which
I confirmed from debug output from the txtinfo
plugin, it is not able maintain connectivity (tcp
and udp streams) with node D</p>
</blockquote>
</div>
<div>and is it able to maintain conenctivtiy with C?<br>
or atleast with A? </div>
<div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p> and my application on node B breaks down. Are
there any settings I am forgetting,</p>
</blockquote>
</div>
<div>if (and only if) u are moving out of range fast, u
might need shorter hello/tc intervals,..</div>
<div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>or is it that UDP data over OLSR is not a good
idea.</p>
</blockquote>
</div>
<div>as long as u do not expect no packetloss, udp works
fine,.. <span><font color="#888888"><br>
</font></span></div>
<span><font color="#888888">
<div><br>
</div>
<div>
<div><br>
Markus</div>
<div><br>
</div>
</div>
</font></span></div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote>
<br>
</div></div>
<br>--<br>
Olsr-users mailing list<br>
<a href="mailto:Olsr-users@lists.olsr.org">Olsr-users@lists.olsr.org</a><br>
<a href="https://lists.olsr.org/mailman/listinfo/olsr-users" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-users</a><br></blockquote></div><br></div>