From: Freifunk Dresden <freifunk@ddmesh.de>
To: b.a.t.m.a.n@open-mesh.net
Subject: Re: [B.A.T.M.A.N.] Memory leak
Date: Mon, 07 Jan 2008 13:56:02 +0100 [thread overview]
Message-ID: <20080107135602.eigmai3tpko40c40@webmail.ddmesh.de> (raw)
In-Reply-To: <200801071045.10747.axel@open-mesh.net>
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.
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).
What IP does the tunnel interface have for the one-way tunnel? Same as
the main
interface? If a client creates a tcp connection then ACKs and answers
should come back through this one-way-tunnel, doesn't it?
What dis/advantages does a two-way-tunnel have against the one-way-tunnel?
For the one-way-tunnel how many tunnel interfaces are created? For
each connecting client one interface or only one interface for all?
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?
Please let me know if there is already a documentation for this.
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. If you have some hints on that, please let me
know.
/Stephan
next prev parent reply other threads:[~2008-01-07 12:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-04 9:57 [B.A.T.M.A.N.] Memory leak Freifunk Dresden
2008-01-04 20:24 ` Axel Neumann
2008-01-05 20:47 ` Freifunk Dresden
2008-01-06 14:03 ` Axel Neumann
2008-01-06 15:52 ` Freifunk Dresden
2008-01-07 9:45 ` Axel Neumann
2008-01-07 12:56 ` Freifunk Dresden [this message]
2008-01-07 16:48 ` [B.A.T.M.A.N.] one-way / two-way tunnel (was: Memory leak) Axel Neumann
2008-01-07 20:52 ` Freifunk Dresden
2008-01-10 8:25 ` Freifunk Dresden
2008-01-17 13:04 ` [B.A.T.M.A.N.] Memory leak Freifunk Dresden
2008-01-20 11:13 ` Axel Neumann
2008-01-26 21:04 ` Freifunk Dresden
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080107135602.eigmai3tpko40c40@webmail.ddmesh.de \
--to=freifunk@ddmesh.de \
--cc=b.a.t.m.a.n@open-mesh.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox