[Olsr-users] trouble with NAT and smart gateway

[Arjun]

Hi Paul,
My network setup looks as follows:
Nodes with interfaces running OLSR (192.168.10.0/24):
A, B, C

Nodes with interfaces not running OLSR (192.168.1.0/24):
C, D

Gateway, announcing HNA4 status:
C

NAT notes:
C runs NAT to masquerade packets coming from the mesh and going to the
non-OLSR 192.168.1.0/24 network.

I am planning to get wifi devices with the atheros chipset and install them
on all my nodes and see if OLSR works. Markus suggested that things get
easier if I use the same wifi devices for all the olsr nodes.
regards,
Arjun.


On Mon, Feb 13, 2012 at 8:35 PM, RC Loh <(spam-protected)> wrote:

> Hi Arjun,
>
> Is it possible that you provide a simple network diagram on where is your
> gateway, node D, node C and node A?
>
> I am also facing some problems in configuring a gateway for my OLSR mesh.
>
> Probably, I can get some inputs from your problem.
>
> Rdgs,
> Paul
>
>
>   *From:* Arjun <(spam-protected)>
> *To:* Vigneswaran R <(spam-protected)>
> *Cc:* (spam-protected)
> *Sent:* Tuesday, 14 February 2012, 5:50
> *Subject:* Re: [Olsr-users] trouble with NAT and smart gateway
>
> Hi Vignesh,
> 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.
> Thanks much!
> Arjun.
>
>
> On Mon, Feb 13, 2012 at 2:32 AM, Vigneswaran R <(spam-protected)>wrote:
>
> 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)> wrote:
>
> afair smart-gateway does not do anything useful for your setup,.
> as its only for hna announcements of 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)> 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
>
>
>
>
>
>
> --
> Olsr-users mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-users
>
>
>
> --
> Olsr-users mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20120214/5f20e1ca/attachment.html>