Hi,

On Samstag 05 Januar 2008, Freifunk Dresden wrote:

Hi,

I have checked the problem a little more. Beside the "top" command on debian can show the same as the "top" does on WRTs. If you press 'H' the threads are also shown. Perhaps the implementation of the "top" or "ps" show the threads too.

There are four batmand threads running. After a while one thread is terminated for about 100 seconds (25 x 4 seconds) and a new thread is created after this time. At this time the memory needs is increased. It seams that at each thread-kill-restart 16 Kbytes are wasted. The virtual assinged memory increases and also the %-Value used.

Does it really increase endlessly with each new thread ? If its the GW-client thread then you can enforce the termination and recreation on-the-fly with batmand -c -r0 (to destroy the tunnel) and -c -r3 (to create the tunnel)

Below you will see the values (memory and pid) delivered by "top" for one incrementation. Hope it gives you a hint. Why is the thread killed and created? There is no client conntected to any router. rdate is restarted periodically and the laptop is telling that it has an internet connection (configured through batmand arguments, which is wanted). Note that the laptop does not have a connection to internet. It just pretends it has one.

there is a blackhole detection in the default two-way-tunnel. This can cause the client to disconnect from the unresponsive (-blackhole-) GW and put the GW on a blacklist for some time. It should all be reported on debug-level 3. If no other GW is available, the GW-client node will reconnect to the GW after a while (might be 100 sec). If you have a dummy GW, either use --no-unresp-gw-check or use --one-way-tunnel 3 at the client and the GW side

/axel

MEM: 1180 8% PIDS:1 -> 893 -> 894 -> 895 -> 2673

Pid 2673 terminates MEM: 1180 8% .... 100 seconds .... MEM: 1180 8% Pid 3751 is created MEM: 1196 9% 1 -> 893 -> 894 -> 895 -> 3751 MEM: 1196 9%

Bye Stephan

---

B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n

hi,

On Sonntag 06 Januar 2008, Freifunk Dresden wrote:

Hi Axel,

...

Does it really increase endlessly with each new thread ? If its the GW-client thread then you can enforce the termination and recreation on-the-fly with batmand -c -r0 (to destroy the tunnel) and -c -r3 (to create the tunnel)

When I call batmand with those parameters I can reproduce this much faster until no memory is available anymore. This happens on each call with these parameters.

ok, I'll check that again. Just to be sure, you observed this on WRT54GL with openWrt Whiterussioin Freifunk firmware? Did you compile the sources yourself or have you used precompiled binaries (which ones)? Because, last time I tried, I applied a lot of -cr0 and -cr3 and the memory usage did not increase endlessly.

...

there is a blackhole detection in the default two-way-tunnel. This can cause the client to disconnect from the unresponsive (-blackhole-) GW and put the GW on a blacklist for some time. It should all be reported on debug-level 3. If no other GW is available, the GW-client node will reconnect to the GW after a while (might be 100 sec). If you have a dummy GW, either use --no-unresp-gw-check or use --one-way-tunnel 3 at the client and the GW side

I like to have the blackhole detection enabled, it is a good way to detect an inactive GW beside of the ping-check-algorithm in the firmware. I assume that default is the two-way-tunnel where data goes from one node directly to the gw and back. Whatfor is the one-way-tunnel and

one-way-tunnel are completely stateless. No assigned virtual IPs, no need for SNAT,... Data is only tunnelled from the GW-Client to the GW-Node. THere it is de-tunnelled and forwarded. We used this setup at the 24c3 to let batman client nodes be accessible via global unique IPs.

what are the condtion for the one-way-tunnel being active.

if you type -cbd2 at a client node you may see: WARNING: You are using BatMan-eXp 0.3-alpha rv898 (compatibility version 10) ! Originator bestNextHop # => 103.131.41.5 103.131.83.5 100, gw_class 49 - 4MBit/1024KBit, reliability: 0, supported tunnel types 2WT, 1WT

2WT indicates the GW capabilities for two-way-tunnel, 1WT indicates ...

--dangerous shows: ... Gateway and tunneling options:

--one-way-tunnel <value> : set preference for one-way-tunnel mode. For GW-nodes: 0 disables this tunnel mode, a larger value enables this tunnel mode. For GW-cliets: 0 disables this tunnel mode, a larger value sets the preference for this mode. default: 1, allowed values: 0 <= value <= 4

--two-way-tunnel <value> : set preference for two-way-tunnel mode. For GW-nodes: 0 disables this tunnel mode, a larger value enables this tunnel mode. For GW-cliets: 0 disables this tunnel mode, a larger value sets the preference for this mode. default: 2, allowed values: 0 <= value <= 4

So essentially, to force a client node to only use one-way tunnel you must start the client with two-way-tunnel disabled (--two-way-tunnel 0 ) . To configure the client node to prefer one-way-tunnel over two-way-tunnel start it with a higher preference for the one-way tunnel (e.g. --one-way-tunnel 3)

bye

/axel

Why is the gw-thread deleted? If the problem lays in the pthread implementation it would be a workaround to keep the gw thread always active.

I also think that the memory consumtion is more than 16kbyte, because the virtual memory is incremented and also the percentage used.

Bye Stephan

---

B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n

On Montag 07 Januar 2008, Freifunk Dresden wrote:

Hi,

The batmand is running on WRT54GL and WRT54GS. The firmware is whiterussian_rc6 and the batmand was self-compiled from within whiterussian devel env. I have removed the "-static" LDFLAG and also removed the DEBUG/MEMORY... CFLAGS. As optimation I have used -Os to keep the batmand small which also produces a lot of warnings.

if you have 30k left, try -O1. Then there should be no warnings.

playing with different optimization levels (all dynamically linked and stripped) : 194783 b with -O1 -DDEBUG_MALLOC -DMEMORY_USAGE -DPROFILE_DATA 190675 b with -O1 162019 b with -O2 174247 b with -O3

I once did some cpu-load experiments to estimate the benifits of -O1..-O3 and could not identify any significant differences between the different compiler optimizations.

By the way, at the 24c3 somebody managed to stip more useless data from the binaries than I achieved with the whiterussion sstrip. Does anybody know how this is possible and what's the difference between strip and sstrip ?

I'm not at home to give you the correct CFLAGS.

...

one-way-tunnel are completely stateless. No assigned virtual IPs, no need for SNAT,... Data is only tunnelled from the GW-Client to the GW-Node. THere it is de-tunnelled and forwarded. We used this setup at the 24c3 to let batman client nodes be accessible via global unique IPs.

I'm still confused about the data traveling over the one/two way tunnels and what the differences are for data travel (request/answer).

an original packet, generated at the client node and forwarded into the bat0 tunnel will be wrapped as UDP payload and send to the GW node. IP src and dst address of the inner (original packet) are not changed. The inner (original) packet does usually contain: - Any global unique IP address from a distant server - the GW-Client node primary batman interface as the src address. The outer IP header will contain: - the GW-Nodes' primary batman interface as the dst address and - the GW-Client nodes' primary batman interface as the src address. Once arrived at the GW-node the inner (original) packet is detunnelled ( unwrapped ) and forwarded to the destination address of the original packet.

Once a reply/answer to the original packet arrives at the GW node it'll contain the GW-Client node primary batman interface as the dst address and is forwarded. Thats it.

What IP does the tunnel interface have for the one-way tunnel? Same as the main interface?

- on the GW-Client node: Yes, same as the primary batman interface - on the GW-Node, depending of what you configured as the GW-tunnel range

( --dangerous: ) --gw-tunnel-network <ip-address/netmask> : set tunnel IP-address range leased out by GW nodes. Only relevant for GW-nodes in two-way-tunnel mode default: 169.254.0.0/22, allowed netmask values: 20 <= value <= 30

If you only want to use one-way-tunnel and do not want to see an ip address here you can use --gw-tunnel-network 0.0.0.0/30 .

If a client creates a tcp connection then ACKs and answers should come back through this one-way-tunnel, doesn't it?

no, answers are not tunnelled, see above.

What dis/advantages does a two-way-tunnel have against the one-way-tunnel?

more cpu load (every downlink packet must be entunnelled and usually you have much more downlink traffic than uplink), less protocol overhead (no additional IP/UDP header), less need for SNAT. See also this thread: https://list.open-mesh.net/pipermail/b.a.t.m.a.n/2007-November/000407.html

For the one-way-tunnel how many tunnel interfaces are created? For each connecting client one interface or only one interface for all?

Always only one, no matter how many clients, secondary interfaces, one-way or two-way tunnel

How does the GW route packets to a specific client if the GW has a route over the wlan interface and a route to the tunnel interface?

If you are talking about a batman GW-node which is participating in the mesh then it should have a host, HNA, or IF route to each other batman node. This will be used for forwarding the packet towards the client node.

If you are talking about a non-batman GW, you must set a network route explicitly to the batman GW-node.

Please let me know if there is already a documentation for this.

in progress... (i see, this answer gets boring)

Currently I'm using the two-way-tunnel and this works find. the only "bad" thing is that the proxy running on the GW does display the 169er IP addresses and not the node main ip. But this is ok.

Perhaps the one-way-tunnel would be better because the memory consumption on the GW.

Memory consumption should usually not be an issue.

If you have some hints on that, please let me know.

/Stephan

---

B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n

Hi,

I have compiled batmand (whiterussian_rc6) with the CFLAGS you provide. There is no change in the behavior when calling "batmand -c -r0" and "batmand -c -r3". On every thread creation the memory consumption rises.

I also have tried to apply "--one-way-tunnel 1 --two-way-tunnel 0" Using the commands above I have the same result. One advantage of the one-way-tunnel is, that the gateway thread is not killed and re-created.

/Stephan

Hi,

can you check if the problem is fixed with rv 957.

regards, axel

On Donnerstag 17 Januar 2008, Freifunk Dresden wrote:

Hi,

has anyone could verify the memory-leak problem (see previous thread). I'm currently use the -one-way-tunnel which does not destroy/recreate the gw thread that is causing the memory consumtion.

jfi: the system is whiterussian rc6, busybox 1.7.2/1.8.2, uclibc 0.27. I still couldn't get uclibc 29 running to check if this causes the problem. Can somebody check this or first verify the problem?

/Stephan _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n