[Olsr-users] trouble with NAT and smart gateway

[Vigneswaran R]

On Saturday 11 February 2012 03:38 AM, Arjun wrote:
[...]
> 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.

I think, NAT can be removed from your setup due to the following reason,

1. OLSR machines have route to D (and it's network) via C (because of HNA)
2. So, the packets originated from OLSR mesh reach C and then forwarded 
to D.
   -- Here, C does simple IP Forwarding (no NATting)
   -- And the forwarded packets will have the source IP unmodified
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).
4. When C receives this reply packet, it routes it to the proper 
destination in the OLSR mesh.


Regards,
Vignesh


> 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.
> Thanks again!
> Arjun.
>
>
> On Fri, Feb 10, 2012 at 2:46 PM, Markus Kittenberger 
> <(spam-protected) <mailto:(spam-protected)>> wrote:
>
>     afair smart-gateway does not do anything useful for your setup,.
>     as its only for hna announcements of 0.0.0.0/0 <http://0.0.0.0/0>
>     (and useful only if u have multiple nodes announcing this)
>
>     anyways to simplify things, do not use smartgateway, hna alone is
>     enough!
>
>     and if possible (to simplify more) also remove the NAT in your
>     testcase, use a static route on your target towards the mesh
>     inestead,..
>
>     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)
>
>     if this simplified setup works, you have issues with nat/hna,..
>     if not, you have problems with mobility (which usually can causes
>     "some" packetloss, and maybe just too much for your udp stream)
>
>     On Fri, Feb 10, 2012 at 7:07 PM, Arjun <(spam-protected)
>     <mailto:(spam-protected)>> wrote:
>
>         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
>
>     and is it able to maintain conenctivtiy with C?
>     or atleast with A?
>
>         and my application on node B breaks down. Are there any
>         settings I am forgetting,
>
>     if (and only if) u are moving out of range fast, u might need
>     shorter hello/tc intervals,..
>
>         or is it that UDP data over OLSR is not a good idea.
>
>     as long as u do not expect no packetloss, udp works fine,..
>
>
>     Markus
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20120213/f09e8277/attachment.html>