Re: [B.A.T.M.A.N.] one-way / two-way tunnel (was: Memory leak)

[Axel Neumann <axel@open-mesh.net>]

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