Re: [B.A.T.M.A.N.] [PATCH] batman-adv: Fixing wrap-around bug in vis

["Linus Lüssing" <linus.luessing@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]

> +		if ((vis_packet->seqno - old_info->packet.seqno) > 127) {
If anyone might have a more generic solution instead of using the
fixed of 127 without having to utilise math.h, that'd be great.

Ok, and no some more words to the tests and discussions with Marek
yesterday and their results.

> What I also just noticed is, that when I refresh the vis-output
> every second only the TQ values of _2_ entries at a time  get updated,
> the other ones are static for quite a while. However, looking at
> wireshark tells me, that I'm still getting a vis-packet of all
> other 4 nodes                                                                                 
> every second. So it looks like the vis-server might not be always
> updating its vis_hash to me, but not sure about that.
The issue seemed to be the thing I just sent a patch for. Pfeh,
then I didn't see any ghost bug which was sometimes there and
sometimes not. I started to doubt about the setup a lot first :).

> I'd expect all 5 nodes to have a direct connection to all other 4
> nodes. However, for instance 06:22:b0:98:87:f9 is just having
> three. A couple of seconds later, the missing entry is there
> again, but other ones can be missing.
The line which is causing this behavior is in generate_vis_packet():
------
398                 if (orig_node->router != NULL
399                         && compare_orig(orig_node->router->addr,
400                                         orig_node->orig)
------
It turned out that this is not a bug and that it was intended to
leave out those vis entries. Looks like I had slightly different
expectations at the vis-server. I wanted to see all possible links
and alternative next-hops in the vis-graph while Marek enlightened
me, that this would increase the throughput usage a lot as for
instance a far distant node, from which we'd receive a batman-ogm
up to every 120 seconds would result into a vis-entry then.
So including alternative/non-used next-hops in the vis-output
might need a new discussion.

Cheers, Linus

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]