From: Axel Neumann <axel@open-mesh.net>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@open-mesh.net>
Subject: Re: [B.A.T.M.A.N.] no gateway / tun interface / default route
Date: Sat, 20 Oct 2007 13:00:00 +0200 [thread overview]
Message-ID: <200710201300.01043.axel@open-mesh.net> (raw)
In-Reply-To: <4718E6AC.9020100@ddmesh.de>
Hello,
> >> >> Laptop: batmand -g 1024/200 -a 104.61.0.0/16 -s 10.12.0.1
> >> >> --no-unreachable-rule --no-throw-rules --no-prio-rules
> >> >> --no-unresp-gw-check --resist-blocked-send wlan0 bbs /t 1 /i bbc /t 1
> >> >> /i wrt54gs: batmand
> >> >>
> >> >> batmand -d 4 -r 2 --t 63 --no-unreachable-rule --no-throw-rules
> >> >> --no-prio-rules --no-unresp-gw-check --resist-blocked-send eth1 bbs
> >> >> /t 1 /i bbc /t 1 /i
> > >
> > > Generally you should announce the ip address of your non-primary
> > > interfaces (bbs and bbc) with HNA. Otherwise the traffic you generate
> > > on these nodes might leave the node with a source IP address which is
> > > simply not known beyond that link. If you really want to completely
> > > hide the IP addresses of bbs and bbc then you need to do NAT for all
> > > locally generated packets, except for the OGMs.
>
> I don't understand your idea.
> Each node in the network has an official ip of the 10.0.0.0/8 network. If I
> use additional interfaces for backbone (bbs,bbc) these interfaces have
> there own ip range 172.16.0.0/12. if a node wants to connect a fare away
> node it will use the "official" ip address from 10.0.0.0/8 range.
Ok if you can ensure this, then there is no problem. But how do you do that?
We observed nodes (also with multiple interfaces and hidden non-primary
interfaces) where local application have chosen the ip address of a
non-primary interface as the source address for its outgoing traffic.
From my understanding, the default behavior of most applications is to always
use the IP address of the interface via which a packet is routed out, as the
source address of an outgoing packet. So in case you send a ping to a node to
which batmand has decided to route via your bbs device, the ping packet
should by default have the IP address of this bbs device. If the destination
node of the ping is link-local for the bbs device, then this is no problem
because all link-local neighbors of bbs have learned about the IP address of
the bbs device. But if the final destination of the ping packet is more than
one hop away, then the destination node does not know anything about the IP
address of bbs unless it has been announced with HNA.
> If the
> only connection is via bbs or bbc the packages are natted to 172.12..
> Only
> the the routers that are connected directly via the backbone (bbc->bbs)
> should have routing entries of 172.16.0.0/12. All other nodes in the
> network do not need to know these addresses and therefore I don't HNA
> these.
How could any non-neighboring node respond to a packet with a 172.12.. source
address?
I would say you better NAT to the IP addresses of your 10.10.0.0/8 because
these are the addresses known by any node. But be careful not to NAT any OGMs
and any forwarded traffic.
> This avoids filling up the routing tables with ip addresses that finally
> point to the same node.
>
> A.eth1-A.bbc=====backbone=========B.bbs-B.eth1
> -------------------C.eth1----------D.eth1 10...1 172...1
> 172...2 10...2 10...3 10...4
>
> Node D with IP 10.12.0.4 can send packages to node 10.12.0.1
> The package is NATed in node B to be send over backbone interface (bbs).
What is the benifit of this NAT here?
> Node A receives this package with ip 172.12.0.1 and because node A has also
> an interface with ip 10.12.0.1 the package has reached the target specified
> by node D (target:10.12.0.1).
Yes I understand that that works from D to A. But does it also work with a
ping send from node A to node D? The source address of the ping request would
be 172.12.0.1 and when it finally arrives at node D, the receiver does not
know how to reply!
ciao,
axel
next prev parent reply other threads:[~2007-10-20 11:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-18 20:14 [B.A.T.M.A.N.] no gateway / tun interface / default route Freifunk Dresden
2007-10-18 23:35 ` Axel Neumann
2007-10-19 10:32 ` Axel Neumann
2007-10-19 10:51 ` Marek Lindner
2007-10-19 17:17 ` Freifunk Dresden
2007-10-19 17:52 ` Marek Lindner
2007-10-19 19:10 ` Freifunk Dresden
2007-10-20 11:00 ` Axel Neumann [this message]
2007-10-21 17:35 ` Freifunk Dresden
2007-10-21 18:07 ` Axel Neumann
2007-10-21 19:41 ` Freifunk Dresden
2007-10-22 12:58 ` Axel Neumann
2007-10-25 10:33 ` Freifunk Dresden
2007-10-25 11:13 ` Axel Neumann
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=200710201300.01043.axel@open-mesh.net \
--to=axel@open-mesh.net \
--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