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
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
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
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
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
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
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
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