[B.A.T.M.A.N.] Texas UML instances and OLSR+BATMAN tests
by Benjamin Henrion
Hi,
I would like to test OLSR and BATMAN on UML instances, since I don't
have the hardware to make real tests.
Would it be possible to have a copy of the binaries running on the
simulator of http://texas.funkfeuer.at/, in order to launch it on my
computer?
Best,
--
Benjamin Henrion <bhenrion(a)ffii.org>
FFII Brussels - +32-484-566109 - +32-2-4148403
13 years
[B.A.T.M.A.N.] batmand terminates silently
by Freifunk Dresden
Hello Axel,
few weeks agoe I had sometimes the problem that batmand (experimental) exits
silently. Today I found maybe one reason for this.
When you have batman running and insert the iptable rule
iptables -I OUTPUT -o eth1 -j DROP
batmand exits. This also happen for additional interfaces controlled
by batmand.
Maybe it helps you a little.
Regards, Stephan
13 years
[B.A.T.M.A.N.] 0.3 beta released
by Marek Lindner
Hi,
the 0.2 branch has proven to be quite stable and robust but with many rough
edges. We used this fundament to work on annoyances and improvements all
over the code to make the upcoming release a worthy successor.
We are very proud to announce that B.A.T.M.A.N. has an official port assigned
by the IANA now. It is 4305 and already in the code. You can see it for
yourself: http://www.iana.org/assignments/port-numbers
Pay attention to the fact that all ports used by B.A.T.M.A.N. are changing:
4305 for OGMs, 4306 for the tunneling and 4307 for the vis server. Adjust
your firewall settings if required.
Another big step forward is our new experimental routing code - we call it
B.A.T.M.A.N. IV. It takes asymmetric routing into account. Currently we have
several ideas competing for the final inclusion into the release. Feel free
to join our testing team.
If you use the stable branch you will find the TQ (Transmit Quality) algorithm
enabled. Each node observes its neighbor nodes and measures the link quality
and adds this information to all (re)broadcasted packets. The clients
choose the route with the best tq value. Use debug level 1 to get the tq
information.
Also, we heavily worked to improve the overall performance of our buitin
tunneling. Therefore we created mod_batgat - a linux kernel module which will
do the job from within the kernel land. It still needs some love and to be
backported to 2.4 but it certainly will be finished for the release.
The whole gateway management received a lot attention. We have new gateway
classes which support down- and upload rates. Just specify your speeds and
B.A.T.M.A.N. will guess the appropriate gateway class. The routing classes
have been reworked as well. The user can choose between fast, stable or
fast-switching connection. The B.A.T.M.A.N. internet client can detect broken
gateways (blackholes) to avoid them. All internet related options can be
changed during runtime. Disabling the own gateway, change the preferred
gateway or routing class is possible without restarting the daemon.
We also improved the quality of our documentation and thanks to the hard work
of Wesley we have a man page with a compete overview about all options
accompanied by a usage example section.
Our vis server was a bit hidden in the past but it steadily made progress and
is now a stable powerful application. It can handle multiple interfaces, HNA
and is small enough to run on embedded devices. We will provide precompiled
packages for it from now on. Therefore we release its first beta version. In
order to avoid confusion in the future the vis server will get the same
version numer as the compatible batman release. That makes it 0.3 beta as
well.
The B.A.T.M.A.N. dev team
13 years, 1 month
[B.A.T.M.A.N.] routing / direct connection
by Freifunk Dresden
Hello,
Im using the batmand- experimental and have some problems with routing.
First I like to know the meaning of all the fields of the debug level
prints and how they are determined.
It would be great If you can give a more detailed information when to
use the extended options and what they do
with batmand. For instance, why should I change the window size (seen in
Graz experiment).
My setup is the following. I have a laptop (linux debian) on a table.
under the table I have a WRT54GS about 50cm below.
A second router WRT54GL is places on the top of a cupboard which is
about 1m higher than the laptop and about 3 m
away. The laptop is offering a gatway.
Table
(wrt B 10.12.10.1)
(laptop 10.12.0.1)
###########
(wrt A 10.12.10.17) #
cupbord ###
laptop ------------ wrt A
| |
wrt B---------------+
My problem is that the connection from the laptop to B is bad (ssh,http
connection). batman setups the routes so each device
has a direct connection to the others.
OLSR has detected this and does not use the direct connection between
laptop and wrt B. It creates an routing entry to
route over wrt A in laptop and wrt B. This results in a fast and better
connection.
laptop wrt A
| |
wrt B---------------+
My problem also causes that the wrt B looses the gatway (laptop) and
removes the default routing entry.
I have added some traces of the three devices. All devices stay directly
connected to each other. After
network start wrt B still shows the gatway of the laptop (over the bad
connection).
Later the gateway will vanish and come back only for a short time before
vanishing again.
LAPTOP:
-----------
batmand -s 10.12.0.1 -g 1024/200 --no-unreachable-rule --no-throw-rules
--no-prio-rules wlan0 bbs /t 1 /i bbc /t 1 /i"
B.A.T.M.A.N. 0.3-exp, MainIF/IP: wlan0 10.12.0.1, WindSize: 128, BLT: 2,
OGI: 1000, UT: 0d 0h 0m
Originator viaIF Router (brc rcvd lseq lvld) [
viaIF l2q lq nlq].. alternatives...
10.12.10.1 wlan0 10.12.10.1 ( 46 47 217 0) [
wlan0 40 48 106] 10.12.10.17 ( 1)
10.12.10.17 wlan0 10.12.10.17 ( 47 48 239 0) [
wlan0 44 49 114] 10.12.10.1 ( 1)
WRT A
---------
batmand --no-unreachable-rule --no-throw-rules --no-prio-rules -r 1 eth1
B.A.T.M.A.N. 0.3-exp, MainIF/IP: eth1 10.12.10.17, WindSize: 128, BLT:
2, OGI: 1000, UT: 0d 0h 3m Originator viaIF Router
(brc rcvd lseq lvld) [ viaIF l2q lq nlq].. alternatives...
10.12.0.1 eth1 10.12.0.1 ( 7 7 7 0) [
eth1 119 7 128] 10.12.10.1 ( 0)
10.12.10.1 eth1 10.12.10.1 (125 126 176 0) [
eth1 115 126 116] 10.12.0.1 ( 1)
Gateway Router (#/128)
=> 10.12.0.1 10.12.0.1 (110), gw_class 33 -
1024KBit/256KBit, reliability: 1
WRT B
---------
batmand --no-unreachable-rule --no-throw-rules --no-prio-rules -r 1 eth1
B.A.T.M.A.N. 0.3-exp, MainIF/IP: eth1 10.12.10.1, WindSize: 128, BLT: 2,
OGI: 1000, UT: 0d 0h 3m
Originator viaIF Router (brc rcvd lseq lvld) [
viaIF l2q lq nlq].. alternatives...
10.12.0.1 eth1 10.12.0.1 ( 23 23 23 0) [
eth1 119 22 128] 10.12.10.17 ( 0)
10.12.10.17 eth1 10.12.10.17 (113 124 213 1) [
eth1 120 113 128] 10.12.0.1 ( 11)
Gateway Router (#/128)
=> 10.12.0.1 10.12.0.1 ( 82), gw_class 33 -
1024KBit/256KBit, reliability: 1
##################
after a while...
LAPTOP:
------------
B.A.T.M.A.N. 0.3-exp, MainIF/IP: wlan0 10.12.0.1, WindSize: 128, BLT: 2,
OGI: 1000, UT: 0d 0h55m
Originator viaIF Router (brc rcvd lseq lvld) [
viaIF l2q lq nlq].. alternatives...
10.12.10.1 wlan0 10.12.10.1 (127 127 3503 0) [
wlan0 107 127 107] 10.12.10.17 ( 0)
10.12.10.17 wlan0 10.12.10.17 (128 128 3532 0) [
wlan0 124 128 124] 10.12.10.1 ( 0)
WRT A
---------
B.A.T.M.A.N. 0.3-exp, MainIF/IP: eth1 10.12.10.17, WindSize: 128, BLT:
2, OGI: 1000, UT: 0d 0h58m
Originator viaIF Router (brc rcvd lseq lvld) [
viaIF l2q lq nlq].. alternatives...
10.12.0.1 eth1 10.12.0.1 (125 126 3301 0) [
eth1 123 125 125] 10.12.10.1 ( 1)
10.12.10.1 eth1 10.12.10.1 (126 128 3470 1) [
eth1 111 128 111] 10.12.0.1 ( 2)
Gateway Router (#/128)
=> 10.12.0.1 10.12.0.1 (125), gw_class 33 -
1024KBit/256KBit, reliability: 1
WRT B
---------
B.A.T.M.A.N. 0.3-exp, MainIF/IP: eth1 10.12.10.1, WindSize: 128, BLT: 2,
OGI: 1000, UT: 0d 0h57m
Originator viaIF Router (brc rcvd lseq lvld) [
viaIF l2q lq nlq].. alternatives...
10.12.0.1 eth1 10.12.0.1 (108 118 3264 0) [
eth1 123 108 128] 10.12.10.17 ( 10)
10.12.10.17 eth1 10.12.10.17 (114 121 3461 0) [
eth1 123 114 128] 10.12.0.1 ( 7)
Gateway Router (#/128)
10.12.0.1 10.12.0.1 (109), gw_class 33 -
1024KBit/256KBit, reliability: 6
##################################################################################
still a little later
LAPTOP:
----------
B.A.T.M.A.N. 0.3-exp, MainIF/IP: wlan0 10.12.0.1, WindSize: 128, BLT: 2,
OGI: 1000, UT: 0d 1h11m
Originator viaIF Router (brc rcvd lseq lvld) [
viaIF l2q lq nlq].. alternatives...
10.12.10.1 wlan0 10.12.10.1 (124 128 4411 0) [
wlan0 107 128 107] 10.12.10.17 ( 4)
10.12.10.17 wlan0 10.12.10.17 (127 127 4441 0) [
wlan0 121 128 121] 10.12.10.1 ( 0)
WRT A
---------
B.A.T.M.A.N. 0.3-exp, MainIF/IP: eth1 10.12.10.17, WindSize: 128, BLT:
2, OGI: 1000, UT: 0d 1h15m
Originator viaIF Router (brc rcvd lseq lvld) [
viaIF l2q lq nlq].. alternatives...
10.12.0.1 eth1 10.12.0.1 (123 125 4308 0) [
eth1 121 123 125] 10.12.10.1 ( 2)
10.12.10.1 eth1 10.12.10.1 (126 128 4477 0) [
eth1 111 128 111] 10.12.0.1 ( 2)
Gateway Router (#/128)
=> 10.12.0.1 10.12.0.1 (123), gw_class 33 -
1024KBit/256KBit, reliability: 1
WRT B
---------
B.A.T.M.A.N. 0.3-exp, MainIF/IP: eth1 10.12.10.1, WindSize: 128, BLT: 2,
OGI: 1000, UT: 0d 1h14m
Originator viaIF Router (brc rcvd lseq lvld) [
viaIF l2q lq nlq].. alternatives...
10.12.0.1 eth1 10.12.0.1 (106 115 4277 0) [
eth1 123 106 128] 10.12.10.17 ( 9)
10.12.10.17 eth1 10.12.10.17 (117 122 4476 0) [
eth1 120 117 128] 10.12.0.1 ( 5)
Gateway Router (#/128)
10.12.0.1 10.12.0.1 (110), gw_class 33 -
1024KBit/256KBit, reliability: 8
13 years, 1 month
[B.A.T.M.A.N.] MAC and OLSR
by giuseppe de marco
I agree that OLSR and also BATMAN should be moved to link layer.
Anyway, now I am trying to do some experiment with OLSR and BATMAN, but
by using also the information of MAC layer.
I am using linux and ieee80211. Does anybody know how to read the mac
parameters, such as
lost frames, number of retransmission and so on?
Regards
--
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
13 years, 1 month
[B.A.T.M.A.N.] a strange case
by a.anselmi＠oltrelinux.com
Hi all
I'm experiencing a strange situation
[AP_n]--wifi--[client]--mesh--[gateway]--wifi--[AP_g]
|
[xDSL]---[world]
The two nodes (client and gateway) are running batman 0.3 (experimental
rv636) in the right way with option --bmx-defaults.
A wifi laptop associated with AP_g (gateway' AP) can browse internet
pretty well while associated with AP_n (client' AP) it can't!
Please note that client itself can browse internet! (I tryed ssh into node
and then wget something).
I verified no nameserver problem neither firewall blocking rules (gateway
and node are flashed and run the same firmware)
But what is puzzling me is that running batman 0.2 on nodes... laptop
associated with AP_n (client' AP) can browse!
(I've only changed the daemon, no others change into environment -
procedures dinamically change batmand command string)
.
I noticed the parameter "--no-unreachable-rule" then tryed adding this
parameter at the batman 0.3 command string but unfortunately with no
results!
Maybe I'm boring you... bat have any ideas about?
--
Antonio
13 years, 1 month
[B.A.T.M.A.N.] 0.3 alpha (today revison)
by a.anselmi＠oltrelinux.com
Hi,
since you use mipsel device I think these mips log could be of more help
in fixing mips/mipsel bug in 0.3 branches (alpha and experimental).
Very simple scenario:
[client 5.1.7.251]----mesh----[gateway 5.1.7.254]
all node running 0.3 apha (the today latest rv6300.3-alpha)
##### d3 level debug at client
...
1) Adding throw route to 169.254.0.0/16 via 0.0.0.0 (table 68 - eth0:1)
2) Adding throw route to 127.0.0.0/8 via 0.0.0.0 (table 68 - lo)
3) Adding throw route to 10.7.251.128/25 via 0.0.0.0 (table 68 - ath2)
4) Adding throw route to 5.0.0.0/8 via 0.0.0.0 (table 68 - ath0)
5) Adding throw route to 10.7.251.0/25 via 0.0.0.0 (table 68 - br0)
6) Adding route to 5.1.7.254 via 0.0.0.0 (table 66 - ath0)
7) Found new gateway 5.1.7.254 -> class: 49 - 4MBit/1024KBit
# after sliding windows if filled in by validate OGMs
8) Adding default route to 5.1.7.254 (gw_flags: 49, packet_count: 64,
gw_product: 0)
9) Adding default route via tun0 (table 68)
# ...ah this is great! now trying to ping outside mesh
10) Gateway client - got IP (1.0.254.169) from gateway: 5.1.7.254
11) Gateway client - gateway (5.1.7.254) says: IP (1.0.254.169) is expired
# client can't exit off mesh
##### d3 level debug at gateway
...
1) gateway class: 49 -> propagating: 4MBit/1024KBit
2) Error - can't add route to 0.0.254.169/24 via 0.0.0.0 (table 254):
Invalid argument
# (don't know why previous error)
# ...gateway is learned about client wants ping outside mesh
3) Gateway - assigned 1.0.254.169 to client 5.1.7.251
4) Error - got packet from unknown client: 5.1.7.251 (virtual ip 1.0.254.169)
What I see:
FIRST BUG (?)
Client prepare route to 169.254.0.0/16 in table 68 (line 1-log_client)
while gateway arrange a 169.254.0.0/24 space (line 2-log_gateway): suffix
bits differs (16 bit netmask client side vs 24 bit netmask server side)
SECOND BUG
Client wants ping outside mesh and receives a *little endian formatted* IP
1.0.254.169 (line 10-log_client and line 3-log_gateway) which is out of
previous arrangement (this IP address is malformed by gateway).
Client tryes sending outgoing packet to gateway
Gateway receives client' outgoing packect but doesn't recognize IP source
address (line 4-log_gateway) expecting one in 0.0.254.169/24 space. Thus
gateway informs client about wrong IP, so client pinging fails (line
11-log_client).
Hopeing this will be usefull... I know today weekend begins :)
--
Antonio
13 years, 1 month
[B.A.T.M.A.N.] assigned IP life
by a.anselmi＠oltrelinux.com
Hi
mybe these lines form -d3 level at client node 5.1.7.251 can help:
Gateway client - got IP (1.0.254.169) from gateway: 5.1.7.254
Gateway client - gateway (5.1.7.254) says: IP (1.0.254.169) is expired
Gateway client - got IP (1.0.254.169) from gateway: 5.1.7.254
Gateway client - gateway (5.1.7.254) says: IP (1.0.254.169) is expired
Gateway client - got IP (1.0.254.169) from gateway: 5.1.7.254
Gateway client - gateway (5.1.7.254) says: IP (1.0.254.169) is expired
Gateway client - got IP (1.0.254.169) from gateway: 5.1.7.254
Gateway client - disconnecting from unresponsive gateway: 5.1.7.254
Deleting default route via bat0 0.0.0.0 (table 67)
-- after some seconds --
Adding default route to 5.1.7.254 (49,64,64)
Adding default route via bat0 0.0.0.0 (table 67)
...seems that lease assigned by gateway to client (IP 1.0.254.169) have a
less than 1 sec of life... almost in my case.
Antonio
13 years, 1 month
Re: [B.A.T.M.A.N.] assigned IP life
by Michael Burmeister-Brown
So how do we fix?
----- Original Message -----
From: b.a.t.m.a.n-bounces(a)open-mesh.net <b.a.t.m.a.n-bounces(a)open-mesh.net>
To: b.a.t.m.a.n(a)open-mesh.net <b.a.t.m.a.n(a)open-mesh.net>
Sent: Fri Sep 21 10:04:55 2007
Subject: [B.A.T.M.A.N.] assigned IP life
Hi
mybe these lines form -d3 level at client node 5.1.7.251 can help:
Gateway client - got IP (1.0.254.169) from gateway: 5.1.7.254
Gateway client - gateway (5.1.7.254) says: IP (1.0.254.169) is expired
Gateway client - got IP (1.0.254.169) from gateway: 5.1.7.254
Gateway client - gateway (5.1.7.254) says: IP (1.0.254.169) is expired
Gateway client - got IP (1.0.254.169) from gateway: 5.1.7.254
Gateway client - gateway (5.1.7.254) says: IP (1.0.254.169) is expired
Gateway client - got IP (1.0.254.169) from gateway: 5.1.7.254
Gateway client - disconnecting from unresponsive gateway: 5.1.7.254
Deleting default route via bat0 0.0.0.0 (table 67)
-- after some seconds --
Adding default route to 5.1.7.254 (49,64,64)
Adding default route via bat0 0.0.0.0 (table 67)
...seems that lease assigned by gateway to client (IP 1.0.254.169) have a
less than 1 sec of life... almost in my case.
Antonio
_______________________________________________
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
13 years, 1 month
