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]
hello,
at http://www.open-mesh.net/wiki/BranchesExplained
you say,
batman 0.3 is the latest stable implementation, using a new version of the algorithm known as the BATMAN IV/TQ algorithm.
Where is the document which describes the BATMAN IV/TQ algorithm in detail?
> 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
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
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
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
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