[Olsr-users] trouble with NAT and smart gateway

Sat Feb 11 19:29:42 CET 2012

Markus,
Yes Node D moves, but I have these problems even when Node D stays static
for several minutes at a location.

Henning,
I did not know that HNA was built into the core olsrd program. When I had
set HNA4 values and not dyn_gw values in the olsrd.conf file, I did not see
any HNA field in the OLSR packet. I did see this HNA field when dyn_gw was
active. This led me to make the wrong assumption that dyn_gw for some
reason works for my case and not the basic HNA4 setting. So I guess the HNA
values are not embedded in every OLSR packet and I just happened to see an
OLSR packet without HNA values the first time around. Anyways, that is
cleared up now.
I can clearly see though, that when my client application is running just
one hop away from the gateway node, it runs perfectly and all the data
comes through. However, when I move the node with my client application
further away from the gateway (note: I placed an intermediate OLSR node to
allow for 2 hop routing), the link quality drops and my client application
stops working. I did wait a minute for the etx values to settle down after
moving the node.
So my question is, my client application works when it is one hop away, why
does it fail when it is two hops away?

attachments:
1. olsrd.conf_gw
2. interfaces_gw
3. olsrd.conf_meshnode
4. interfaces_meshnode

On the gateway, node C, I also use an iptables rule to do masquerading for
packets exiting through the interface that connects to the toy, i.e.
192.168.1.2 (wlan1).

Thanks much!
Arjun.

On Sat, Feb 11, 2012 at 3:39 AM, Markus Kittenberger <
(spam-protected)> wrote:

> maybe he meant the dyngw plugin,..
>
> Markus
>
>
> On Sat, Feb 11, 2012 at 9:37 AM, Henning Rogge <(spam-protected)>wrote:
>
>> The switch "smartgateway on/off" should have nothing to do with a node
>> publishing HNAs. In fact, smartgateway just reads the incoming HNAs
>> and modify outgoing 0.0.0.0/0 HNAs, it doesn't create one on its own.
>>
>> I am not sure what you mean with "smart_gw" plugin... the
>> Smart-Gateway code is part of the core, it is not in a plugin at all.
>> Can you maybe post your olsrd.conf file so we can see how you
>> configured your mesh?
>>
>> Henning Rogge
>>
>> On Fri, Feb 10, 2012 at 23:08, Arjun <(spam-protected)> wrote:
>> > Hi Markus,
>> > 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.
>> > 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 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
>>
>>
>>
>> --
>> "Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand
>> ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt
>> Marti)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20120211/6822a533/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: olsrd.conf_gw
Type: application/octet-stream
Size: 451 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20120211/6822a533/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: interfaces_gw
Type: application/octet-stream
Size: 297 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20120211/6822a533/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: olsrd.conf_meshnode
Type: application/octet-stream
Size: 486 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20120211/6822a533/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: interfaces_meshnode
Type: application/octet-stream
Size: 206 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20120211/6822a533/attachment-0003.obj>