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