[B.A.T.M.A.N.] Batman gateway lock ups
by Outback Dingo
see pastebin
http://www.pastebin.ca/1194874
pertinent info
dmesg | grep 'batgat loaded'
batgat: [init_module:96] batgat loaded rv1025
uname -a
Linux nightwing 2.6.23.16 #16 Tue Apr 22 20:00:17 ART 2008 mips unknown
root@nightwing:~# 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 (compatibility version 5)
lsmod
Module Size Used by Tainted:
P
sch_htb 14048
2
ath_ahb 103616
0
wlan_xauth 480
0
wlan_wep 4000
0
wlan_tkip 9856
0
wlan_ccmp 5440
2
wlan_acl 1920 0
ath_rate_minstrel 8352 1
ath_hal 136832 3 ath_ahb,ath_rate_minstrel
wlan_scan_sta 8768 1
wlan_scan_ap 6656 0
wlan 152464 10
ath_ahb,wlan_xauth,wlan_wep,wlan_tkip,wlan_ccmp,wlan_acl,ath_rate_minstrel,wlan_scan_sta,wlan_scan_ap
batgat 10944 1
ipt_iprange 672 0
ipt_TOS 832 0
ipt_TTL 928 0
xt_MARK 960 3
ipt_ECN 1472 0
xt_CLASSIFY 640 0
ipt_ttl 704 0
ipt_tos 544 0
ipt_time 1568 0
xt_tcpmss 1088 0
xt_statistic 832 0
xt_mark 672 7
xt_mac 736 3
xt_length 736 0
ipt_ecn 1024 0
xt_DSCP 1056 0
xt_dscp 832 0
imq 2096 0
ipt_IMQ 672 2
xt_string 896 0
xt_layer7 9840 0
ipt_ipp2p 6784 0
ipt_LOG 4640 0
xt_CHAOS 1792 0
xt_DELUDE 2624 1
xt_TARPIT 2816 1
xt_quota 800 0
xt_portscan 2016 0
xt_pkttype 704 0
xt_physdev 1488 0
ipt_owner 800 0
iptable_raw 832 0
xt_NOTRACK 832 0
xt_CONNMARK 1088 0
ipt_recent 4992 0
xt_helper 992 0
xt_conntrack 1312 0
xt_connmark 832 0
xt_connbytes 1312 0
tun 6592 0
11 years, 9 months
[B.A.T.M.A.N.] originators says yes, batping says no
by Jacob Marble
I have three nodes running OpenWrt r16484 (SVN) and batman-advanced
r1298. All nodes show each other in originators. batping gets host
unreachable for all relationships, and the host unreachable messages
come very quickly, maybe 1000/second. Here is a log sample, log_level
4. log_level 11 doesn't show anything.
The setup I'm using worked fine with r1176. Using ahdemo.
[ 42949625] Received BATMAN packet via NB: 00:15:6d:a7:6a:9e, IF:
ath0 [00:15:6d:a7:6a:9c] (from OG: 00:15:6d:a7:6a:9e, via old OG:
00:15:6d:a7:6a:9e, seqno 214, tq 255, TTL 50, V 7, IDF 0)
[ 42949625] updating last_seqno: old 213, new 214
[ 42949625] bidirectional: orig = 00:15:6d:a7:6a:9e neigh =
00:15:6d:a7:6a:9e => own_bcast = 64, real recv = 64, local tq: 255,
asym_penality: 255, total tq: 255
[ 42949625] update_originator(): Searching and updating originator
entry of received packet
[ 42949625] Updating existing last-hop neighbour of originator
[ 42949625] Forwarding packet: tq_orig: 255, tq_avg: 255, tq_forw:
250, ttl_orig: 49, ttl_forw: 49
[ 42949625] Forwarding packet: rebroadcast neighbour packet with
direct link flag
[ 42949625] Sending own packet (originator 00:15:6d:a7:6a:9c, seqno
216, TQ 255, TTL 50, IDF off) on interface ath0 [00:15:6d:a7:6a:9c]
[ 42949625] Received BATMAN packet via NB: 00:15:6d:a7:6a:14, IF:
ath0 [00:15:6d:a7:6a:9c] (from OG: 00:15:6d:a7:6a:9e, via old OG:
00:15:6d:a7:6a:9e, seqno 214, tq 240, TTL 49, V 7, IDF 1)
[ 42949625] bidirectional: orig = 00:15:6d:a7:6a:9e neigh =
00:15:6d:a7:6a:14 => own_bcast = 63, real recv = 64, local tq: 251,
asym_penality: 255, total tq: 236
[ 42949625] update_originator(): Searching and updating originator
entry of received packet
[ 42949625] Updating existing last-hop neighbour of originator
[ 42949625] Drop packet: duplicate packet received
[ 42949625] Forwarding packet (originator 00:15:6d:a7:6a:9e, seqno
214, TQ 240, TTL 49, IDF on) on interface ath0 [00:15:6d:a7:6a:9c]
[ 42949625] Received BATMAN packet via NB: 00:15:6d:a7:6a:9e, IF:
ath0 [00:15:6d:a7:6a:9c] (from OG: 00:15:6d:a7:6a:9c, via old OG:
00:15:6d:a7:6a:9c, seqno 216, tq 236, TTL 49, V 7, IDF 1)
[ 42949625] Drop packet: originator packet from myself (via neighbour)
[ 42949625] Received BATMAN packet via NB: 00:15:6d:a7:6a:14, IF:
ath0 [00:15:6d:a7:6a:9c] (from OG: 00:15:6d:a7:6a:9c, via old OG:
00:15:6d:a7:6a:9c, seqno 216, tq 240, TTL 49, V 7, IDF 1)
[ 42949625] Drop packet: originator packet from myself (via neighbour)
[ 42949625] Received BATMAN packet via NB: 00:15:6d:a7:6a:14, IF:
ath0 [00:15:6d:a7:6a:9c] (from OG: 00:15:6d:a7:6a:14, via old OG:
00:15:6d:a7:6a:14, seqno 205, tq 255, TTL 50, V 7, IDF 0)
[ 42949625] updating last_seqno: old 204, new 205
[ 42949625] bidirectional: orig = 00:15:6d:a7:6a:14 neigh =
00:15:6d:a7:6a:14 => own_bcast = 64, real recv = 64, local tq: 255,
asym_penality: 255, total tq: 255
[ 42949625] update_originator(): Searching and updating originator
entry of received packet
[ 42949625] Updating existing last-hop neighbour of originator
[ 42949625] Forwarding packet: tq_orig: 255, tq_avg: 254, tq_forw:
250, ttl_orig: 49, ttl_forw: 49
[ 42949625] Forwarding packet: rebroadcast neighbour packet with
direct link flag
[ 42949625] Received BATMAN packet via NB: 00:15:6d:a7:6a:9e, IF:
ath0 [00:15:6d:a7:6a:9c] (from OG: 00:15:6d:a7:6a:14, via old OG:
00:15:6d:a7:6a:14, seqno 205, tq 240, TTL 49, V 7, IDF 1)
[ 42949625] bidirectional: orig = 00:15:6d:a7:6a:14 neigh =
00:15:6d:a7:6a:9e => own_bcast = 64, real recv = 64, local tq: 255,
asym_penality: 255, total tq: 240
[ 42949625] update_originator(): Searching and updating originator
entry of received packet
[ 42949625] Updating existing last-hop neighbour of originator
[ 42949625] Drop packet: duplicate packet received
[ 42949625] Forwarding packet (originator 00:15:6d:a7:6a:14, seqno
205, TQ 240, TTL 49, IDF on) on interface ath0 [00:15:6d:a7:6a:9c]
11 years, 9 months
[B.A.T.M.A.N.] [PATCH] [batman-adv] Convert to new net_device_ops
by Sven Eckelmann
The current version of batman-adv-kernelland uses the netdevice
structure instead of netdevice ops introduced by
v2.6.28-rc5-510-gd314774. The compatibility version was removed in
v2.6.30-rc6-851-ge3804cb. We need to change now change to this new
structure to be able to compile it against linux-2.6.31.
Signed-off-by: Sven Eckelmann <sven.eckelmann(a)gmx.de>
---
batman-adv-kernelland/soft-interface.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/batman-adv-kernelland/soft-interface.c b/batman-adv-kernelland/soft-interface.c
index bb95501..4600017 100644
--- a/batman-adv-kernelland/soft-interface.c
+++ b/batman-adv-kernelland/soft-interface.c
@@ -31,6 +31,7 @@
#include "hash.h"
#include <linux/ethtool.h>
#include <linux/etherdevice.h>
+#include "compat.h"
@@ -98,6 +99,18 @@ int my_skb_push(struct sk_buff *skb, unsigned int len)
return 0;
}
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 29)
+static const struct net_device_ops bat_netdev_ops = {
+ .ndo_open = interface_open,
+ .ndo_stop = interface_release,
+ .ndo_get_stats = interface_stats,
+ .ndo_set_mac_address = interface_set_mac_addr,
+ .ndo_change_mtu = interface_change_mtu,
+ .ndo_start_xmit = interface_tx,
+ .ndo_validate_addr = eth_validate_addr
+};
+#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 29) */
+
void interface_setup(struct net_device *dev)
{
struct bat_priv *priv = netdev_priv(dev);
@@ -105,12 +118,16 @@ void interface_setup(struct net_device *dev)
ether_setup(dev);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29)
dev->open = interface_open;
dev->stop = interface_release;
dev->get_stats = interface_stats;
dev->set_mac_address = interface_set_mac_addr;
dev->change_mtu = interface_change_mtu;
dev->hard_start_xmit = interface_tx;
+#else
+ dev->netdev_ops = &bat_netdev_ops;
+#endif /* LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29) */
dev->destructor = free_netdev;
dev->features |= NETIF_F_NO_CSUM;
--
1.6.3.1
11 years, 9 months
Re: [B.A.T.M.A.N.] originator tq_avg oscilations
by Andrew Lunn
> If you are willing to test a few things to reduce the effect we can
> start right away. You could set TQ_GLOBAL_WINDOW_SIZE to 1 in order
> to deactivate the averaging of the TQ values. Aslo, some people
> reported that reducing the hop penalty also will increase the speed.
I already tried changing TQ_GLOBAL_WINDOW_SIZE to 5 instead of 10 and
that helped. Changing it to one is interesting. I've not tried it yet,
but i would of thought some ring buffer was needed to handle the 0s
which are added when originator messages are received for other
neighbors.
I already tried reducing the hop penalty. However testing showed it
behaved worse. This i don't understand. So i'm guessing my test setup
changed between my different tests. So i need to run the test again,
both the control and the modified hop penalty.
What ideas do you have for improving the algorithms. Depending on the
scale of work needed i might have some time to do some coding.
Andrew
11 years, 9 months
[B.A.T.M.A.N.] Recommended Reading for those that want to get involved with B.A.T.M.A.N.
by Andrew de Andrade
Dear all,
I've been signed up to the list for a few weeks now and I was
wondering if you
guys could recommend a reading list for those who would like to get
involved
with B.A.T.M.A.N.
I'm currently halfway through "Computer Networking: A Top Down Approach"
by James F. Kurose and Keith W. Ross, however it is only provides a
general
theoretical overview of networking as it exists today. Mesh networking
is
something far more advanced, so I was wondering if there were particular
textbooks, journal articles and other material that members of this
list could
recommend.
Recommend anything and everything that you guys think is relevant, both
directly and indirectly.
thx!
Andrew
11 years, 9 months
[B.A.T.M.A.N.] ring buffer average function...
by Andrew Lunn
Hi Folks
Can somebody explain why this function works the way it does:
uint8_t ring_buffer_avg(uint8_t lq_recv[])
{
uint8_t *ptr;
uint16_t count = 0, i = 0, sum = 0;
ptr = lq_recv;
while (i < TQ_GLOBAL_WINDOW_SIZE) {
if (*ptr != 0) {
count++;
sum += *ptr;
}
i++;
ptr++;
}
if (count == 0)
return 0;
return (uint8_t)(sum / count);
}
It only averages over the none zero values.
The code filling these ring buffer puts a zero in whenever an
originator message is received from another neighbor. When the
originator message is from this neighbor, the tq in the originator
message is put in.
When a neighbor is dead, the ring slowly fills with 0's, whenever
there is an originator message from one of the other
neighbors. However since the 0 are ignored when calculating the
average, we tend to have a cliff effect for dead neighbors. There
tq_avg stays about the same for quite a while, and then plummets to 0.
For faster detecting dead neighbors, it would be better if the 0 were
included in the average. The tv_avg would then drop more linearly, not
cliff like, so it is likely to cross below another neighbors tv_avg
earlier, so re-routing around the dead node faster.
Before i change this function, i just want to understand why it is
like this, and what i'm likely to break :-(
Thanks
Andrew
11 years, 9 months
[B.A.T.M.A.N.] originator tq_avg oscilations
by Andrew Lunn
Hi Folks
I've been playing with B.A.T.M.A.N advanced for a few weeks now.
One of the scenarios where we might want to use it is nomadic
vehicles. Each vehicle has a wifi radio which is used to build a mesh
between the vehicles when the vehicles are parked together at a
location. I said the vehicles are nomadic. By that i mean they tend to
stay in one place for a while, and then move on. They can move
individually, or in groups. For the moment we are not interested in
meshing while on the move.
I've run into a "problem" when one vehicle/node moves away from the
rest of the vehicles/nodes. It is taking a long time for the mesh to
realize the node has gone and rebuild the mesh. With a 500ms
orig_interval in our little test network, pings get lost for an
average of 26 seconds. The variation is great, sometimes it reroutes
in 10 seconds, sometimes in 50 seconds.
So i want to improve this. The first thing i did was make some plots
of the tq_avg value, as shown in /proc/net/batman-adv/originators. I
look at one particular originator and plot the different tq_avg values
for the list of neighbors. Attaches is a png image showing this.
I was surprised to see that its unstable and oscillating. The
different tq_avg values mostly oscillate together, as shown in the
figure, but i've also seen cases when they oscillate 180 degrees out
of phase. In that case, the routing flips on the cross overs.
Is this normal? Is it expected behavior?
Has anybody worked on making re-routing around disappears nodes
faster?
Thanks
Andrew
11 years, 9 months
[B.A.T.M.A.N.] Clarification of version number in batctl/main.h
by Sven Eckelmann
Hi,
I just wanted to ask how to interpret the current version number of batctl.
Does it mean that the current version in svn is before or after a possible
0.2-beta release? Is it important for me because debian differentiates between
before and after something. For example 0.2~beta would mean that there is a
beta version before the 0.2 release. So I wanted to know if should call a svn
snapshot of the current batctl 0.2~beta~svn1317 (svn1317 snapshot before a
possible 0.2~beta release) or 0.2~beta+svn1317 (svn1317 snapshot after the
beta phase has started - no beta version will ever be made available or has
been released already).
It seems that the 0.2~beta~svn1317 is the more "correct" version as it has
less extra rules than 0.2~beta+svn1317. For example there must not be an extra
rule for events like the release of 0.3.1 of batman when Simon changed the
version string to 0.3.1 in 1177 which was before the release of 0.3.1 and thus
shouldn't be called 0.3.1+svn1177.
Can this be interpreted the same way for all other on open-mesh.net published
hosted projects? So if I would create a snapshot version of batman it would
have the version number 0.4~beta~svn1309?
Regards,
Sven
11 years, 9 months
