Hi Markus,<div>Thanks for your reply. I did try setting only the HNA4 values in the olsrd.conf file on my gateway node. However, it did not result in any HNA messages being sent out as part of the OLSR packets. I verified this by peering into the OLSR packet through wireshark. Using the smart_gw plugin resulted in the HNA messages showing up inside the OLSR packets.</div>

<div>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. </div>
<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>