[B.A.T.M.A.N.] [PATCH 0/3] Staging: Batman-adv: Bug fixes for 2.6.34-rc2.
by Andrew Lunn
Hi Greg
Here are three patches against 2.6.34-rc2 which we would like including
into the next -rc kernel. All three are bug fixes, with the first being a
regression relative to 2.6.33 and the second two being older bugs, prescent
in 2.6.33.
Thanks
Andrew
Andrew Lunn (1):
Staging: batman-adv: don't have interrupts disabled while sending.
Linus Luessing (1):
Staging: batman-adv: Fix VIS output bug for secondary interfaces
Linus Lüssing (1):
Staging: batman-adv: Fixing wrap-around bug in vis
drivers/staging/batman-adv/proc.c | 51 ++++++---
drivers/staging/batman-adv/vis.c | 235 +++++++++++++++++++++++++------------
drivers/staging/batman-adv/vis.h | 8 +-
3 files changed, 202 insertions(+), 92 deletions(-)
10 years, 1 month
[B.A.T.M.A.N.] reorganized kernel interface patches (version 3)
by Marek Lindner
Hi,
since my last patches did not trigger too many complaints I went ahead and
submitted them. This opens the way for the last series of patches which
conclude the matter. All remaining /proc files have been eliminated and moved
over to /sys. While doing so, I reworked the interface handling to satisfy an
old feature request: interfaces can be added & removed on the fly.
On startup batman-adv will scan the system for available interfaces to create
a "batman_adv" subfolder in their respective /sys/class/net folder, e.g.
eth0: /sys/class/net/eth0/batman_adv
This subfolder will contain the settings which are relevant for this
interface. You can tell batman-adv to use an interface by writing "bat0" into
the mesh_iface file:
echo bat0 > /sys/class/net/eth0/batman_adv/mesh_iface
or write "none" to deactivate it:
echo none > /sys/class/net/eth0/batman_adv/mesh_iface
Although only "bat0" is accepted at this point, the syntax already gears
towards multiple virtual mesh support. Later you will be able to create/name
your virtual meshes by writing into this file. Retrieve the interface status by
simply reading its status file:
cat /sys/class/net/eth0/batman_adv/iface_status
Note: batman-adv will continuously observe the system's interfaces. Whenever
new interfaces appear or disappear batman will update the /sys/class/net
folders automatically. Also, batman-adv will make sure that incompatible
interfaces (e.g. loopback, non-ethernet, etc) won't have the subfolder, hence
can't be activated.
The batctl interface syntax had to be modified in order to cope with these
changes. You can run:
batctl interface
to get the list of active interfaces and their status. To add or delete
interfaces you can run:
batctl interface add|del eth0 eth1 ..
Since removing an active interface is a tricky thing where many operations can
go wrong I expect some crashes/race conditions in the code. I tested it a
while on multiple machines with multiple interfaces and it works for me but
I'm sure there are more bugs to find.
Regards,
Marek
10 years, 1 month
[B.A.T.M.A.N.] batman-adv 0.2.1 released
by Marek Lindner
The B.A.T.M.A.N. team hereby announces the release of the first bugfix milestone
for the batman-adv 0.2 branch which focuses on stability but also brings
improvements and small changes. As the kernel module always depends on the
Linux kernel it was compiled against, it does not make sense to provide
binaries on our website. As usual, you will find the signed tarballs in our
download section:
http://downloads.open-mesh.net/batman/releases/batman-adv-0.2.1/
as well as prepackaged binaries in your distribution.
Important changes
----------------
The batman-adv logging facilities underwent structural changes to fully
integrate into the standard Linux logging mechanisms. Please study the README
to get further details on how to access the debug logs. In addition, the "vis"
/proc file has been split up into two files: vis_server and vis_data. The
vis_server controls the vis server status whereas the vis_data file exports the
visualization "raw" data which can be easily parsed by user space tools.
Again, details can be found in our documentation.
Thanks
----------------
Special thanks go to:
* Andrew Lunn for going through the entire code base to refactor the code and
adjust the coding style to match standard Linux coding style guidelines
* Linus Luessing for his restless testing in so many scenarios and sending a
lot of patches and suggestions.
Thanks to all people sending in patches:
* Andrew Lunn <andrew(a)lunn.ch>
* Julia Lawall <julia(a)diku.dk>
* Linus Luessing <linus.luessing(a)web.de>
* Marek Lindner <lindner_marek(a)yahoo.de>
* Simon Wunderlich <siwu(a)hrz.tu-chemnitz.de>
* Sven Eckelmann <sven.eckelmann(a)gmx.de>
* Sven-Thorsten Dietrich <sdietrich(a)novell.com>
batman-adv
----------------
Albeit being a bugfix release we dared to include some bigger changes because
we felt their gain outweighs the risk. For instance, we replaced the packet
handling thread which was responsible for routing the payload data through the
mesh by an advanced skbuff handling technique. Now, packets are received
directly by registering the Ethernet type and handling skbs instead of self-
allocated buffers which boosts the performance considerably and reduces
latency.
On the other hand batman-adv is moving towards full Linux kernel integration
which requires some significant changes under the hood as well as on the
surface. Batman's own logging facility has been removed (the standard Linux
logging is used instead). The vis output comes now in a neutral format, easily
parsable by user space applications. Since the module entered the official Linux
realm several people threw static code analyzers (e.g. Coccinelle, sparse)
onto the code to find bugs. Some (possible) memory leaks, optimizations and a
false alarms have been found and dealt with. Many more bugs, race conditions
and crashes have been fixed. Now, it also is possible to change the MAC address
on bat0.
batctl
----------------
Since the vis output format has changed, batctl received a parser for the
neutral format to convert the output into either dot draw or JSON. If you wish
to write your own parser, please see our documentation and/or the batctl code
as an example. The batman-adv debug log will show up in the standard kernel
logs of your system, hence to access the logs "batctl log" is not needed any
longer. Please use the tools provided by your distribution
(dmesg/logread/syslog/etc). However, "batctl log" remains available and can be
used to filter existing logfiles for batman-adv output and to replace the mac
addresses by bat-host names.
Happy routing,
The B.A.T.M.A.N. team
10 years, 2 months
[B.A.T.M.A.N.] [PATCH] batman-adv: Update README about vis raw output
by Linus Lüssing
We are now having a newer, more neutral vis output so that we won't have
to change the kernelmodule for adding support of new vis output formats.
This patch adds an explanation about this in the README file of
batman-adv and removes the description about the dot/json format (they
will be added to the README of batctl).
Signed-off-by: Linus Lüssing <linus.luessing(a)web.de>
---
README | 43 ++++++++++++++++++++++++++++---------------
1 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/README b/README
index df21c61..2058a13 100644
--- a/README
+++ b/README
@@ -1,4 +1,4 @@
-[state: 01-01-2010]
+[state: 21-03-2010]
BATMAN-ADV
----------
@@ -57,10 +57,11 @@ regular interface:
# ping 192.168.0.2
...
+---
If you want topology visualization, your meshnode must be configured
as VIS-server:
-# echo "server" > /proc/net/batman-adv/vis
+# echo "server" > /proc/net/batman-adv/vis_server
Each node is either configured as "server" or as "client" (default:
"client"). Clients send their topology data to the server next to them,
@@ -71,19 +72,31 @@ more vis servers sharing the same (or at least very similar) data.
When configured as server, you can get a topology snapshot of your mesh:
-# cat /proc/net/batman-adv/vis
-
-This output format is a graphviz formatted text file which can be
-processed with graphviz-tools like dot.
-The labels are similar/compatible to the ETX metric, 1.0 means perfect
-connection (100%), 2.0 means 50%, 3.0 means 33% and so on.
-
-Alternatively, a JSON output format is available. The format can be set
-using by writing either "dot_draw" or "json" into the vis_format file.
-"dot_draw" is selected by default.
-
-echo "json" > /proc/net/batman-adv/vis_format
-
+# cat /proc/net/batman-adv/vis_data
+
+This raw output is intended to be easily parsable and convertable with
+other tools. Have a look at the batctl README if you want a vis output
+in dot or json format for instance and how those outputs could then be
+visualised in an image.
+
+The raw format consists of comma seperated values per entry where each
+entry is giving information about a certain source interface. Each entry
+can/has to have the following values:
+-> "mac" -> mac address of an originator's source interface
+ (each line begins with it)
+-> "TQ mac value" -> src mac's link quality towards mac address of a neighbor
+ originator's interface which is being used for routing
+-> "HNA mac" -> HNA announced by source mac
+-> "PRIMARY" -> this is a primary interface
+-> "SEC mac" -> secondary mac address of source (requires preceeding
+-> PRIMARY)
+
+The TQ value has a range from 4 to 255 with 255 being the best.
+The HNA entries are showing which hosts are connected to the mesh via bat0
+or being bridged into the mesh network.
+The PRIMARY/SEC values are only applied on primary interfaces
+
+---
In very mobile scenarios, you might want to adjust the originator
interval to a lower value. This will make the mesh more responsive to
topology changes, but will also increase the overhead. Please make sure
--
1.7.0
10 years, 2 months
[B.A.T.M.A.N.] [PATCH] batman-adv: Remove dead max addr #define
by Linus Lüssing
It's not being used anywhere and just misleading, therefore removing it.
Signed-off-by: Linus Lüssing <linus.luessing(a)web.de>
---
main.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/main.h b/main.h
index 307a6e6..17d26be 100644
--- a/main.h
+++ b/main.h
@@ -34,8 +34,6 @@
#define TQ_MAX_VALUE 255
#define JITTER 20
#define TTL 50 /* Time To Live of broadcast messages */
-#define MAX_ADDR 16 /* number of interfaces which can be added to
- * batman. */
#define PURGE_TIMEOUT 200000 /* purge originators after time in ms if no
* valid packet comes in -> TODO: check
--
1.7.0
10 years, 2 months
[B.A.T.M.A.N.] [PATCH 1/2] batman-adv: fix aggregation timing bug
by Linus Lüssing
From: Marek Lindner <lindner_marek(a)yahoo.de>
batman-adv aggregates routing packets to reduce the number of packets in
the air. Every outgoing packet is compared with other packets in the
buffer to determine whether it can be aggregated or not. Packets sent
at a lower interval can be held back longer to maximize the aggregation.
Due to insufficient checking batman-adv held back all packets for a
certain time depending on its own lowest interval rate which slowed
down all other nodes.
Reported-by: Linus Luessing <linus.luessing(a)web.de>
Signed-off-by: Marek Lindner <lindner_marek(a)yahoo.de>
---
aggregation.c | 12 ++++++++++++
send.c | 10 +---------
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/batman-adv-kernelland/aggregation.c b/batman-adv-kernelland/aggregation.c
index a829814..0635b5a 100644
--- a/batman-adv-kernelland/aggregation.c
+++ b/batman-adv-kernelland/aggregation.c
@@ -52,6 +52,8 @@ static bool can_aggregate_with(struct batman_packet *new_batman_packet,
*/
if (time_before(send_time, forw_packet->send_time) &&
+ time_after_eq(send_time + msecs_to_jiffies(MAX_AGGREGATION_MS),
+ forw_packet->send_time) &&
(aggregated_bytes <= MAX_AGGREGATION_BYTES)) {
/**
@@ -196,6 +198,16 @@ void add_bat_packet_to_list(unsigned char *packet_buff, int packet_len,
if (forw_packet_aggr == NULL) {
/* the following section can run without the lock */
spin_unlock_irqrestore(&forw_bat_list_lock, flags);
+
+ /**
+ * if we could not aggregate this packet with one of the others
+ * we hold it back for a while, so that it might be aggregated
+ * later on
+ */
+ if ((!own_packet) &&
+ (atomic_read(&bat_priv->aggregation_enabled)))
+ send_time += msecs_to_jiffies(MAX_AGGREGATION_MS);
+
new_aggregated_packet(packet_buff, packet_len,
send_time, direct_link,
if_incoming, own_packet);
diff --git a/batman-adv-kernelland/send.c b/batman-adv-kernelland/send.c
index 1c82f43..4320855 100644
--- a/batman-adv-kernelland/send.c
+++ b/batman-adv-kernelland/send.c
@@ -49,15 +49,7 @@ static unsigned long own_send_time(void)
/* when do we schedule a forwarded packet to be sent */
static unsigned long forward_send_time(struct bat_priv *bat_priv)
{
- unsigned long send_time = jiffies; /* Starting now plus... */
-
- if (atomic_read(&bat_priv->aggregation_enabled))
- send_time += (((MAX_AGGREGATION_MS - (JITTER/2) +
- (random32() % JITTER)) * HZ) / 1000);
- else
- send_time += (((random32() % (JITTER/2)) * HZ) / 1000);
-
- return send_time;
+ return jiffies + (((random32() % (JITTER/2)) * HZ) / 1000);
}
/* send out an already prepared packet to the given address via the
--
1.7.0
10 years, 2 months
[B.A.T.M.A.N.] B.A.T.M.A.N Suitability for MAGIC 2010
by Michael Fazio
Hello,
My name is Michael. I am currently working on a large robotics
project and I am thinking of using B.A.T.M.A.N to facilitate a MANET
to communicate between a number of bots and a base station. I was
hoping to get a bit of information regarding the suitability of
B.A.T.M.A.N for such an application. Any information would be helpful
(general or specific). Here are some of the details of our project.
We will be using up-to 14 bots in our project (each must be network
aware).
The area that our bots will be operating in is approximately the size
of a football field.
There are both indoor and outdoor areas that must be navigated with a
significant amount of obstacles.
We will be using 802.11a,b,g and possibly n as well as one or more
long range VHF links which I am hoping to setup as additional entry
points to our bot network.
We have various types of data to be communicated on our network
including, GPS, basic telemetry, control message, imagery, UAV feeds,
point cloud info etc.
Some data such as GPS and telemetry is realtime and need not be
reliable (we are considering simply UDP broadcasting this data). Other
data such as imagery and control messages will require stable links
and need to be relatively reliable.
We are not yet sure if we will be deploying any specific middleware
technology although I am partial to pub/sub middleware. Are there any
such middleware that can complement B.A.T.M.A.N?
I was hoping to know what type of issues I might run into using
B.A.T.M.A.N adv in such a scenario. For instance, what kind of
throughput might I expect in the described environment? Link stability
issues? General suitability? How would B.A.T.M.A.N compare to OLSR or
Babel? I am really interested in anything that anyone has to offer.
The reason I am pushing for B.A.T.M.A.N is because of the ability for
us to develop our application layer using IPv4 TCP/UDP on-top of a
mesh network driven by routers running openWRT & B.A.T.M.A.N. I want
to take as much network layer knowledge away from out application layer.
Also, does anyone know of other similar usages of B.A.T.M.A.N?
I have a bunch of studies from various organizations comparing
B.A.T.M.A.N to other solutions but I would really appreciate to hear
what the mail list users have to say about their own experiences with
B.A.T.M.A.N.
I hope this is the right place to be asking all these questions!
Thanks Batmen & Batwomen!
Michael
10 years, 2 months
