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