Hi,
I massaged the RFC patches a little longer to integrate all the feedback
received so far. They are ready to be considered 'real' patches now.
The 'dynamically load routing kernel module' feature has not found its
way into my patchset. At this point I still see no benefit and only
complications. The mentioned reasons (kernel folks might not like it /
helps to better abstract) can be addressed in a different way (for
example asking David if he is going to accept it or not). The only
reason seems to be "because we can". That's not enough for me.
This does not mean we can't add this feature at a later point in time
when we have the feeling it actually brings some benefits.
Here the changelog:
* sysfs documentation added
* changed batman iv function prefix to bat_iv
* renamed struct bat_algo to struct bat_algo_ops
* all bat_algo_ops callbacks are mandatory for now
* added struct bat_algo_ops documentation
* introduced bat_algo.h for the routing algo init calls
* bat_algo_ops->name became a pointer
* removed all (unnecessary) locking from bat_algo_*
Cheers,
Marek
On Tuesday 06 December 2011 15:18:03 Marko Panger - AGB Lab wrote:
> Sven,
Please don't mail me in private without a good reason. At least Cc
b.a.t.m.a.n(a)lists.open-mesh.org for batman-adv related things.
> This is a very important info. Gigabyte is the provider of the HW and if
> this is related to the driver I have to report them. We had some
> problems already with this driver as it doesn't set the cell number
> correctly.
It sounds more like Ralink... but that is not important right now ;)
But maybe you can provide more information about the driver (which exact
driver did you use, ...) because some people on the mailing list may have used
the same driver and know a workaround/fix.
> Could you give me a hint how to provide such information to them ?
The same way you contacted us... with a lot of information. But try to use a
small tool to send unicast packets in one direction and look if you can create
the same situation without batman-adv involved. IP is not the best solution
because it has to send more packets and therefore create more problems when
you just want to test a simple scenario. I usually use a small program that
directly sends one small ethernet frame to another node over the selected
interface while the other side only waits for this packet on a specific
interface. So nothing really complicated.
The receiver side has to start the program like this:
$ ./rawsend ra0
and the sender has to start it with the MAC of the receiver
$ ./rawsend ra0 ca:fe:ba:de:ba:be
The receiver will exit the rawsend after it finished the receive.
So start the setup without batman-adv. Try to contact the nodes, restart the
one node you always restarted in your tests and try to communicat with it. You
can also use broadcast (just use the mac ff:ff:ff:ff:ff:ff as target) to test
if unicast is the only problem.
I hope this helps to document the problem. This should allow the driver author
to debug/reproduce the whole scenario. But please send us more information
when this is not the problem and really batman-adv's fault.
Kind regards,
Sven
Hi,
I'm evaluating the possibility to use batman in our next product
(measurement equipment) and I'm facing problems in using batman.
I have five nodes installed around and I experience black-outs in
connection among nodes. The resoult is I can't ping a certain node anymore.
Here is the output from 'batctl o' and the subsequent ping to a node
which has good link quality (TQ):
[root@gtam00119 ~]# batctl o
[B.A.T.M.A.N. adv 2011.4.0, MainIF/MAC: ra0/48:5d:60:b8:a2:f6 (bat0)]
Originator last-seen (#/255) Nexthop [outgoingIF]:
Potential nexthops ...
48:5d:60:b8:a2:b7 0.974s (202) 48:5d:60:b8:a3:0e [ ra0]:
48:5d:60:b8:a2:d2 ( 0) 48:5d:60:b8:a3:0e (202)
48:5d:60:b8:a3:0e 0.439s (249) 48:5d:60:b8:a3:0e [ ra0]:
48:5d:60:b8:a2:d2 (231) 48:5d:60:b8:a3:0e (249)
48:5d:60:b8:a2:d2 0.749s (250) 48:5d:60:b8:a2:d2 [ ra0]:
48:5d:60:b8:a3:0e (235) 48:5d:60:b8:a2:d2 (250)
48:5d:60:b8:a2:ff 0.156s (209) 48:5d:60:b8:a3:0e [ ra0]:
48:5d:60:b8:a2:d2 ( 0) 48:5d:60:b8:a3:0e (209)
[root@gtam00119 ~]# batctl ping 48:5d:60:b8:a3:0e
PING 48:5d:60:b8:a3:0e (48:5d:60:b8:a3:0e) 20(48) bytes of data
Reply from host 48:5d:60:b8:a3:0e timed out
Reply from host 48:5d:60:b8:a3:0e timed out
Reply from host 48:5d:60:b8:a3:0e timed out
Reply from host 48:5d:60:b8:a3:0e timed out
And this is the output from 'batctl ll tt routes' from he node that is
being pinged (see above):
[ 63665] Sending TT_REQUEST to 48:5d:60:b8:a2:b7 via
48:5d:60:b8:a2:ff [.]
[ 63665] TT inconsistency for 48:5d:60:b8:a2:ff. Need to retrieve
the correct information (ttvn: 1 last_ttvn: 0 crc: 19133 last_crc: 0
num_changes: 0)
[ 63666] TT inconsistency for 48:5d:60:b8:a2:b7. Need to retrieve
the correct information (ttvn: 1 last_ttvn: 0 crc: 22851 last_crc: 0
num_changes: 0)
[ 63666] TT inconsistency for 48:5d:60:b8:a2:ff. Need to retrieve
the correct information (ttvn: 1 last_ttvn: 0 crc: 19133 last_crc: 0
num_changes: 0)
[ 63666] Sending TT_REQUEST to 48:5d:60:b8:a2:ff via
48:5d:60:b8:a2:ff [.]
[ 63667] TT inconsistency for 48:5d:60:b8:a2:b7. Need to retrieve
the correct information (ttvn: 1 last_ttvn: 0 crc: 22851 last_crc: 0
num_changes: 0)
[ 63667] TT inconsistency for 48:5d:60:b8:a2:ff. Need to retrieve
the correct information (ttvn: 1 last_ttvn: 0 crc: 19133 last_crc: 0
num_changes: 0)
[ 63668] TT inconsistency for 48:5d:60:b8:a2:b7. Need to retrieve
the correct information (ttvn: 1 last_ttvn: 0 crc: 22851 last_crc: 0
num_changes: 0)
[ 63668] TT inconsistency for 48:5d:60:b8:a2:ff. Need to retrieve
the correct information (ttvn: 1 last_ttvn: 0 crc: 19133 last_crc: 0
num_changes: 0)
[ 63669] TT inconsistency for 48:5d:60:b8:a2:b7. Need to retrieve
the correct information (ttvn: 1 last_ttvn: 0 crc: 22851 last_crc: 0
num_changes: 0)
This situation was triggered by the following procedure:
1) from node (last two octets) 'a2:f6' the 'a3:0e' node was pinged
2) in the middle a ssh connection from the node 'a2:f6' was made to the
node 'a3:0e'.
3) so far so good
4) the node 'a3:0e' was rebooted by issuing the 'reboot' command in the
console
5) after this the connection is lost and the above logs were produced
I'm using the version 2011.4.0 on all nodes:
[root@gtam00119 ~]# batctl -v
batctl 2011.4.0 [batman-adv: 2011.4.0]
Any help is highly appreciated. I might be doing something wrong, but
seems a stability problem.
Marko
I have used batman on my project for several months.It performs very well,stable especially!
But,actually,I am not satisfied with the performance of Batman.I found that the bandwidth would drop sharply with the wireless hop increase.
Now I provide my test result here:
routerA and routerB is composed of compex wp543ahv mainboard (AR7161 platform) and two AR9220 wireless card.Firmware is Openwrt backfire.
one card is working on 2.4G channel as AP mode,the other is working on 5G channel as mesh backbone
batman version:2.0
notebook1 and notebook2 is equiped with 802.11n usb wireless card which access to the AP mode card of routerA and routerB
channel 1 channel 36 channel 11
notebook1 --------------- routerA -------------- routerB -------------- notebook2
I use iperf to test bandwidth
notebook1 ----------- routerA 45Mbps
routerA ----------- routerB 46Mbps
routerB ----------- notebook2 45Mbps
But the bandwidth between notebook1 and notebook2 remains 8Mbps
bandwidth between notebook1 and routerB remain 18Mbps
So the conclution is that the bandwidth will be halfed with the 1 hop increase! right?
I also found that the interface alternating mode and bonding mode doesn't take effect
channel 1
routerA ------------------ routerB
channel 36
The test result is no difference whatever I configured alternating or bonding or just single radio
According to the batman official site, alternating or bonding mode would improve the performance compared with the single radio mode
looking forward somebody's help
highly appreciated!
When receiving a DEL change for a client due to a roaming event (change is
marked with TT_CLIENT_ROAM), each node has to check if the client roamed
to itself or somewhere else.
In the latter case the global entry is kept to avoid having no route at all
otherwise we can safely delete the global entry
Signed-off-by: Antonio Quartulli <ordex(a)autistici.org>
---
translation-table.c | 21 ++++++++++++++++++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/translation-table.c b/translation-table.c
index cf3e2c2..6e01079 100644
--- a/translation-table.c
+++ b/translation-table.c
@@ -663,6 +663,7 @@ void tt_global_del(struct bat_priv *bat_priv,
const char *message, bool roaming)
{
struct tt_global_entry *tt_global_entry = NULL;
+ struct tt_local_entry *tt_local_entry = NULL
tt_global_entry = tt_global_hash_find(bat_priv, addr);
if (!tt_global_entry)
@@ -670,15 +671,29 @@ void tt_global_del(struct bat_priv *bat_priv,
if (tt_global_entry->orig_node == orig_node) {
if (roaming) {
- tt_global_entry->common.flags |= TT_CLIENT_ROAM;
- tt_global_entry->roam_at = jiffies;
- goto out;
+ /* if we are deleting a global entry due to a roam
+ * event, there are two possibilities:
+ * 1) the client roamed from node A to node B => we mark
+ * it with TT_CLIENT_ROAM, we start a timer and we
+ * wait for node B to claim it. In case of timeout
+ * the entry is purged.
+ * 2) the client roamed to us => we can directly delete
+ * the global entry, since it is useless now. */
+ tt_local_entry = tt_local_hash_find(bat_priv,
+ tt_global_entry->addr);
+ if (!tt_local_entry) {
+ tt_global_entry->common.flags |= TT_CLIENT_ROAM;
+ tt_global_entry->roam_at = jiffies;
+ goto out;
+ }
}
_tt_global_del(bat_priv, tt_global_entry, message);
}
out:
if (tt_global_entry)
tt_global_entry_free_ref(tt_global_entry);
+ if (tt_local_entry)
+ tt_local_entry_free_ref(tt_local_entry);
}
void tt_global_del_orig(struct bat_priv *bat_priv,
--
1.7.3.4
> GOOD DAY
>
> MY NAME AND FLAVIO LEONEL
> I am Brazilian MORO near Sao Paulo 100 KM.
>
> MESH NETWORKS AND I'M STUDYING A FEW MONTHS AND THEY ALREADY KNOW A FEW
> YEARS.
> I am testing two U.S. "FOLLOW THE MAP NETWORK STRUCTURE"
>
>
> STRUCTURE OF RADIO NETWORK
>
> NODE BASE:
> UNIFI Ubiquiti AP WITH OpenWRT RC6 backfire, BATMAN-ADV AND DRIVER ATH9
> for
> Atheros
> INTERFECAE 1: MODE: 802.11s CONNECTED TO NODE 2
> 2 INTERFACE: VIRTUAL WLAN AP MODE = "WI-FI IN TO MY HOUSE AND POSSIBLE
> NEXT
> CUSTOMER"
> 3 BR-LAN INTERFACE WITH BATMAN-ADV ACTIVE
> LINK UP WITH LAN = MikroTik
>
> NODE 2:
> M2 HP Ubiquiti Bullet
> Backfire OpenWRT RC6, BATMAN-ADV AND DRIVER ATH9 for Atheros
> INTERFECAE 1: MODE: 802.11s CONNECTED WITH THE BASE NODE
> 2 INTERFACE: VIRTUAL WLAN AP MODE = "WIFI FOR CUSTOMERS"
> 3 BR-LAN INTERFACE WITH BATMAN-ADV ACTIVE
> LAN = WINDOWS PC LINK
>
> ROUTING STRUCTURE OF INTERNAL NODES:
> ALL INTERFACES IN BRIDGE
> BRIDGES WITH INTERFACE FOR MONITORING 10.1.137.0/24 IPS.
> FIREWALL OpenWRT "iptables"
> TCP + UDP FORWARD
>
> Default router by the firewall
> "images attached"
>
> SUPER RUN THIS WELL WITH BATMAN-ADV
> SO I'M HAVING A PROBLEM THAT STILL DO NOT UNDERSTAND IS WHERE THE ERROR
> NODE 2 MY CLIENT HAS a wired LAN CONNECTED IN THE RADIO As you can see the
> network map.
> THIS IS IT YOU OFF THE COMPUTER AND I RESTART THE RADIO WITH HIM HE
> DISCONNECTED BY ANY RULE NO MORE VOUT to connect eth0 DISABLE RADIO
> ELEA WAS DISABLED AS ME BUT NO PHYSICAL CONNECTION OR COMMUNICATION WITH
> OWN
> AP.
> DETAIL THIS CAN HELP ME I'M BREAKING THE HEAD
>
>
>
> And I like to better understand and make an alliance with any VCS HERE IN
> BRAZIL
> BECAUSE I am excited about the BATMAND ADV WE HAVE A POOR BUT STILL
> AVAILABLE DOCUMENTATION
>
> Another question HOW THE QUALITY OF BATMAN-LINK
>
> HUG
> I HOPE YOU UNDERSTAND MY PROBLEM AND WE CAN TALK MORE
>
Whenever we add a local client for which we already have a global entry, the
latter has to be marked with the TT_CLIENT_ROAM flag (instead of
TT_CLIENT_PENDING)
Signed-off-by: Antonio Quartulli <ordex(a)autistici.org>
---
translation-table.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/translation-table.c b/translation-table.c
index 7a7df4a..cf3e2c2 100644
--- a/translation-table.c
+++ b/translation-table.c
@@ -242,9 +242,11 @@ void tt_local_add(struct net_device *soft_iface, const uint8_t *addr,
if (tt_global_entry) {
/* This node is probably going to update its tt table */
tt_global_entry->orig_node->tt_poss_change = true;
- /* The global entry has to be marked as PENDING and has to be
+ /* The global entry has to be marked as ROAMING and has to be
* kept for consistency purpose */
- tt_global_entry->common.flags |= TT_CLIENT_PENDING;
+ tt_global_entry->common.flags |= TT_CLIENT_ROAM;
+ tt_global_entry->roam_at = jiffies;
+
send_roam_adv(bat_priv, tt_global_entry->common.addr,
tt_global_entry->orig_node);
}
--
1.7.3.4
Hi David,
the following 10 patches constitute the first batch I'd like to get the pulled
into net-next-2.6/3.3. They're mostly uncritical fixes around the recently
introduced tt code, some code refactoring, the kstrto update and the range
check fix reported by Thomas Jarosch.
Thanks,
Marek
The following changes since commit 1ea6b8f48918282bdca0b32a34095504ee65bab5:
Linux 3.2-rc1 (2011-11-07 16:16:02 -0800)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git for_david
Antonio Quartulli (5):
batman-adv: tt_global_del_orig() has to print the correct message
batman-adv: use orig_hash_find() instead of get_orig_node() in TT code
batman-adv: fixed hash functions type to uint32_t instead of int
batman-adv: linearise the tt_response skb only if needed
batman-adv: check for tt_reponse packet real length
Marek Lindner (1):
batman-adv: refactoring gateway handling code
Simon Wunderlich (2):
batman-adv: directly write tt entries without buffering
batman-adv: Fix range check for expected packets
Sven Eckelmann (2):
batman-adv: update internal version number
batman-adv: Replace obsolete strict_strto<foo> with kstrto<foo>
net/batman-adv/bat_sysfs.c | 4 +-
net/batman-adv/bitarray.c | 2 +-
net/batman-adv/gateway_client.c | 153 ++++++++++++++++++++++--------------
net/batman-adv/gateway_client.h | 5 +-
net/batman-adv/gateway_common.c | 4 +-
net/batman-adv/hash.c | 4 +-
net/batman-adv/hash.h | 13 ++--
net/batman-adv/main.h | 2 +-
net/batman-adv/originator.c | 13 ++-
net/batman-adv/originator.h | 2 +-
net/batman-adv/routing.c | 22 ++++--
net/batman-adv/soft-interface.c | 43 +++++++---
net/batman-adv/translation-table.c | 100 ++++++-----------------
net/batman-adv/vis.c | 17 +++--
14 files changed, 202 insertions(+), 182 deletions(-)
in an multi-line if statement leading edges should line up to the opening
parenthesis
Reported-by: David Miller <davem(a)davemloft.net>
Signed-off-by: Antonio Quartulli <ordex(a)autistici.org>
---
routing.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/routing.c b/routing.c
index d5ddbd1..4363d19 100644
--- a/routing.c
+++ b/routing.c
@@ -627,8 +627,7 @@ int recv_tt_query(struct sk_buff *skb, struct hard_iface *recv_if)
/* Ensure we have all the claimed data */
if (unlikely(skb_headlen(skb) <
- sizeof(struct tt_query_packet) +
- tt_len))
+ sizeof(struct tt_query_packet) + tt_len))
goto out;
handle_tt_response(bat_priv, tt_query);
--
1.7.3.4