[Olsr-users] trouble with NAT and smart gateway

Wed Feb 15 19:42:27 CET 2012

Hi Teco,
Thanks for your help! I have only one gateway which connects between two
subnets. One subnet is 192.168.10.0 and the other subnet is 192.168.1.0. I
am now planning to run olsr on wifi devices using the same chipset and the
same driver. I hope that will give me better results.

Paul,
Please keep me posted. I will do likewise.

best,
Arjun.

On Tue, Feb 14, 2012 at 10:54 AM, Teco Boot <(spam-protected)> wrote:

>
> Op 14 feb. 2012, om 15:48 heeft Arjun het volgende geschreven:
>
> 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
>
> 2 nodes with same HNA?
>
> I suggest the following:
> Allocate a /24 to each node:
> A: 192.168.1.0/24
> B: 192.168.2.0/24
> C: 192.168.3.0/24
> And on MANET interfaces:
> A: 192.168.10.1/24
> B: 192.168.10.2/24
> C: 192.168.10.3/24
> Configure interfaces, olsr config etc.
> Then check IP connectivity on each link (ping). Check with arp, tcpdump
> etc.
> Probably and hopefully it works on your current gear.
>
>
> 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.
>
> not again :-((
>
> Teco
>
>
>
> 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
>>
>>
> --
> 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/20120215/b16d3d14/attachment.html>