[B.A.T.M.A.N.] policy routing improved
by Marek Lindner
Hi,
after several talks with different batman users / freifunk communities it
became clear that we need more flexibility for the policy routing. Therefore
I implemented a new option which takes a path to a executable / shell script
as argument (--policy-routing-script). If this option is given batmand will
send all routing table changes to this executable instead of manipulating the
routing table itself. The messages contain all neccessary information to
manipulate the routing table correctly. The executable can modify the
parameters before changing the routing table (routing tables, interfaces,
priorities, etc) or just ignore messages.
I wrote a sample shell script which you can use as basis for your hacking:
http://downloads.open-mesh.net/batman/useful-scripts-and-tools/policy_rou...
This makes the --no-policy-routing option obsolete which was removed.
Feedback is welcome. ;-)
Greetings,
Marek
15 years, 1 month
[B.A.T.M.A.N.] Some issues in ahdemo and intra-mesh traffic (slow)
by Predrag Balorda
I'm running 5 nodes in 11b ahdemo + vap configuration, everything unbridged
and on separate subnets, even lan ports. It's really self-explanatory, but
for the uninitiated - being poor and not having money for a "proper" mesh
router with two or more wireless cards I'm running batman on ahdemo
interface for mesh routing and each router also has a vap for client access
(atheros hardware here, Broadcom routers 105.0.4.4 and 105.0.4.5 attach to
the mesh via another vap). I have chosen 11b over 11g for slightly better
range and better stability.
I'm experiencing strange behavior. Throughput between notes is roughly
2mbits (around 300KB/sec scp transfers).
I have included my digraph in PS so that you can better visualize my
network.
After a minute, for example node 5 would stop responding to pings from node
3, or node 1 from 4 etc, so basically two-hop nodes, direct neighbours
always seem ok. But the funny thing is that hosts on the internet, i.e.
traffic that goes to the tunnel always respond to pings. I have tried
experimenting with one-way tunnel mode but I have been unsuccessfull. Tried
"--one-way-tunnel 1 --two-way-tunnel 0" on both gw and client batman nodes
but nothing happens, batmand -c -d 2 always shows 2WT capability for the
gateway.
I have tried --dups-ttl 2 --re-brc-delay 15 --window-size 100 (reading from
bmx tutorial pdf) and it has helped somewhat, but not completely. The
problem is still there but to a lesser extent.
I don't know whether this is down to ahdemo (maybe Antonio can help here
with his experience) or down to batman. Any ideas?
Also, is my throughput ok compared to yours? The most I ever got was around
450KB/s (roughly 5.5mbits data rate, distance 100m outside with 9dbi omni
antennas and atheros 5112 - buffalo whr-hp-ag108 at both ends) but the
11Mbits evades me - even on a -55 signal and 40 rssi! It really is heart
breaking, especially seeing such a good signal. Two nodes roughly 300m apart
get 240KB/s at most. I know better is possible because in ap mode with that
signal I used to get 1MB/s transfers (that was before I started using batman
and ahdemo).
Best regards,
Pele
P.S.
digraph topology
{
"105.0.4.4" -> "105.0.4.5"[label="1.15"]
"105.0.4.4" -> "105.0.3.3"[label="1.05"]
"105.0.4.4" -> "10.0.4.0/255.255.255.0"[label="HNA"]
"105.0.4.4" -> "10.1.4.0/255.255.255.0"[label="HNA"]
"105.0.4.4" -> "105.0.2.4/255.255.255.255"[label="HNA"]
"105.0.3.3" -> "105.0.0.1"[label="1.16"]
"105.0.3.3" -> "105.0.4.4"[label="1.19"]
"105.0.3.3" -> "105.0.3.2"[label="1.05"]
"105.0.3.3" -> "105.0.4.5"[label="1.12"]
"105.0.3.3" -> "10.0.3.0/255.255.255.0"[label="HNA"]
"105.0.3.3" -> "10.1.3.0/255.255.255.0"[label="HNA"]
"105.0.3.3" -> "105.0.0.3/255.255.255.255"[label="HNA"]
"105.0.3.3" -> "105.0.2.3/255.255.255.255"[label="HNA"]
"105.0.3.3" -> "105.0.1.3/255.255.255.255"[label="HNA"]
"105.0.4.5" -> "105.0.4.4"[label="1.27"]
"105.0.4.5" -> "105.0.3.3"[label="1.03"]
"105.0.4.5" -> "10.0.5.0/255.255.255.0"[label="HNA"]
"105.0.4.5" -> "105.0.2.5/255.255.255.255"[label="HNA"]
"105.0.3.2" -> "105.0.0.1"[label="1.03"]
"105.0.3.2" -> "105.0.3.3"[label="1.03"]
"105.0.3.2" -> "10.0.2.0/255.255.255.0"[label="HNA"]
"105.0.3.2" -> "10.1.2.0/255.255.255.0"[label="HNA"]
"105.0.3.2" -> "105.0.0.2/255.255.255.255"[label="HNA"]
"105.0.3.2" -> "105.0.2.2/255.255.255.255"[label="HNA"]
"105.0.3.2" -> "105.0.1.2/255.255.255.255"[label="HNA"]
"105.0.0.1" -> "105.0.3.3"[label="1.03"]
"105.0.0.1" -> "105.0.3.2"[label="1.01"]
"105.0.0.1" -> "10.0.1.0/255.255.255.0"[label="HNA"]
"105.0.0.1" -> "10.1.1.0/255.255.255.0"[label="HNA"]
"105.0.0.1" -> "105.0.2.1/255.255.255.255"[label="HNA"]
"105.0.0.1" -> "105.0.1.1/255.255.255.255"[label="HNA"]
"105.0.0.1" -> "0.0.0.0/0.0.0.0"[label="HNA"]
}
15 years, 1 month
[B.A.T.M.A.N.] (no subject)
by giuseppe de marco
Anybody know a good embedded harware to use for test batman?
G
--
Giuseppe De Marco, PhD
Toyota Technological Institute
468-8511 Aichi 2-12-1 Hisakata, Tenpaku-ku,
Nagoya, Japan
Email: demarco at toyota-ti dot ac dot jp
Tel (int): +81 (052)-809-1802
Skype-Id: giuseppe_dem2
15 years, 1 month
[B.A.T.M.A.N.] strange batman aborting
by Jan Hetges
Hi All
after two weeks uptime bmxd_rv804 just died! and not only that one,
but on a neighbouring node (~5 days uptime) as well.
So i restarted them, and about 26hrs later, they are both dead again.
So i enabled Lui's watchout4batman, maybe i see at least, which one
dies first. Only unnormal in the log:
user.warn kernel: nf_conntrack: table full, dropping packet.
any ideas?
cheers
--Jan
p.s. both boxes run kamikaze 7.07 i386
15 years, 1 month
[B.A.T.M.A.N.] In-the-field Protocol Migration (was: exp-rv811 and exp-864 non-interoperable?)
by Axel Neumann
Hi,
On Montag 10 Dezember 2007, Predrag Balorda wrote:
> Before I go round upgrading my routers, are these two incompatible because
> it seems so?
Yes, everyting < 863 is incompatible with revisions >= 863
> If so then I'll need to figure out the exact order of
> upgrading (i.e furthest first - I don't want to have to climb roofs or walk
> too long)
The following should be possible even without any upgrading order - allowing a
completely seamless, in-the-field protocol migration. May sound a bit
oversized but is probably the only way for large-chaotic mesh networks.
In short this approach involves three steps:
1) Install the new batman version in parallel to the existing one
(ensure independent operation of the two protocols, more details below...)
2) Test the new batman version
3) Disable the old batman version
Now the long and detailed howto. Don't be afraid it turns out to be much
easier than it first sounds.
0) You keep your current revision running as it is.
1) Install the new version in parallel to the existing one.
Do NOT enable GW-client mode (-r of -p) before step 2.
Configure the new version with independent:
a) alias interfaces and IP ranges
( e.g. use eth0:bmx 103.x.y.z/8 in addition to eth0:bat 105.x.y.z/8 )
Ensure that the old batmand gets (re-)started after the new alias interfaces
and ip ranges have been configured. Thus, either
- you only restart the old batmand after the new interface configuration or
- you put the bat and bmx alias-interface configuration in your startup
scripts and reboot your device.
The reason for this is that batman learns about the networks of a node during
its startup process and takes care that packets towards these networks are
not routed into the batman tunnel. Because we don't want the 103.0.0.0/8
traffic (related to the new batmand) to be routed via the bat0 tunnel of the
old batmand, we have to make sure that the old batmand knows about it.
b) binary name (e.g. rename the binary to /usr/sbin/bmxd)
c) protocol port numbers ( e.g. use 14305 instead of 4305 )
d) ip preference rules (e.g. use 14xxx instead of 6xxx)
e) ip routing tables (e.g. use table 144-148 instead of 64-68 )
f) gateway tunnel ip ranges
(e.g. use bat1 169.254.128.0/22 instead of bat0 169.254.0.0/22 )
g) unix-socket identifier to access debug messages
The good thing is, the --neta option cares for task
c,d,e,f,g automatically, so the only tasks left are the binary names and
the interface configuration (and of course the annoying firewall
configuration)
2) Now - when the new version is installed everywhere - it can be tested.
So fare GW-Client mode should not have been activated with the new version.
Therefore, the first testing can only involve the routing inside the mesh, the
cpu load of the new version,...
One note, to access the debug output of the new batman version
use --neta -cd1 , the verbose output has moved to debug-level 8 (--neta -cd8)
To test internet connectivity I assume that the nodes which were operating in
GW-mode with the old batmand are also operating in GW-mode with the new
batman version.
But so fare GW-Client mode has not been activated with the new version. The
GW-Client mode (e.g. -r 3) configures your default route and there can be
only ONE default route per node. So here each node/user has to make a choice.
The good thing is, this choice can now be done independently at each node.
Since revision 811 (this is before the compatibility change) you can use
-c -r 0 to dynamically deactivate GW-client mode with the old batman
and --neta -c -r 3 to dynamically activate GW-client mode with the new
version.
3) Once every node and user is convinced that using the new batman version for
routing and surfing the internet pays out (thus uses -r 0 with the old batman
and -r 3 with the new version) the old version can be gradually deactivated.
happy routing,
axel
>
> Best regards,
>
> Pele
>
> P.S. also has anyone compared network throughput between beta and exp and
> are there any benefits to beta over exp?
> P.P.S I'm experimenting with PoE and guess which process is the first that
> gets killed because of undervoltage?! :-)
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N(a)open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
15 years, 1 month
[B.A.T.M.A.N.] two-way-tunnel quirks
by Jan Hetges
Hi all
as i'm running bmxd-rv804 only ;-)
for almost two weeks now, almost without problems...
now i found an issue which i didn't relate with batman
first. I got several reports of users, hotmail/msn/live.com
not being accessible anymore...
Yesterday i found out theres also problems with some pop server
not beeing accessible, but everything works fine directly at the
upstream gw, without any batmand involved.
reenableing the old one-way-tunnel solved all the problems.
cheers
--Jan
15 years, 1 month
[B.A.T.M.A.N.] open-mesh certificate
by Marek Lindner
> Batman-0.3 and batman-adv disappeared from the ftp server?
>
> A major re-naming effort underway perhaps?
>
> P.S. I've grabbed some sources just in case your ftp server is dying J
Thanks for your hints. But it is to earlier to bring open-mesh under the
earth. ;-)
The SSL certificate has expired and as soon as this is fixed everything will
go back to normal.
Regards,
Marek
15 years, 2 months
[B.A.T.M.A.N.] rv791 <---> rv824 incompatible?
by tetzlav
> root@17-21:~# batmand
> -v
>
> B.A.T.M.A.N. 0.3-beta rv791 (compatibility version 4)
> root@17-21:~# batmand -cd4
> [ 33051930] Received BATMAN packet via NB: 105.61.17.32, IF: eth1:bat
> 105.61.17.21 (from OG: 4.0.50.0, via old OG: 31.213.16.210, seqno
> 4384, tq 17, TTL 61, V 61, UDF 0, IDF 1)
> [ 33051930] Is an internet gateway (class 105)
> [ 33051930] Drop packet: incompatible batman version (61)
---
> root@17-32:~# batmand -v
> WARNING: You are using the unstable batman branch. If you are
> interested in *using* batman get the latest stable release
> !
> B.A.T.M.A.N. 0.3-beta rv824 (compatibility version 4)
> root@17.32:~# batmand -cd4
> [ 7946500] Received BATMAN packet via NB: 105.61.17.21, IF: eth1:bat
> 105.61.17.32 (from OG: 0.254.113.181, via old OG: 0.4.117.105, seqno
> 26941, tq 61, TTL 18, V 105, UDF 0, IDF
> 0)
>
> [ 7946500] Is an internet gateway (class 1)
> [ 7946510] Drop packet: incompatible batman version (105)
Regards
tetzlav
15 years, 2 months
