public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: "Linus Lüssing" <linus.luessing@web.de>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: [B.A.T.M.A.N.] vis: (sometimes) missing entries
Date: Wed, 10 Mar 2010 00:03:08 +0100	[thread overview]
Message-ID: <20100309230308.GB30949@Linus-Debian> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 4914 bytes --]

Hi guys,

Ok, and the second bug, which has been there even before the 0.2
release if I remember right, is, that seemingly random entries in
the vis-servers output are missing, even when having a setup with
single-interface nodes only. The probability seems to increase the
more nodes are in the mesh network. For instance, I'm right now
running a setup of 4 wifi routers + my laptop with the current
batman-adv maintenance version with my last vis patch. They are
all right next to each other and connected over wifi, therefore
they're all in the same neighbourhood. No downloads or any other
highly disturbing wifi traffic around.

With just 3 routers, there are only missing entries from time to
time, but with 5 devices, there is usually always at least one
entry missing. For example:

-----------------------------------------------------------------
sh-4.1# ./batctl vd dot && ./batctl o
digraph {
        "06:22:b0:98:94:0b" -> "06:22:b0:98:87:f9" [label="1.20"]
        "06:22:b0:98:94:0b" -> "06:22:b0:44:c6:59" [label="1.0"]
        "06:22:b0:98:94:0b" -> "00:13:e8:50:c0:ff" [label="1.0"]
        "06:22:b0:98:94:0b" -> "06:22:b0:44:94:5d" [label="1.20"]
        "06:22:b0:98:94:0b" -> "00:22:b0:98:94:0b" [label="HNA"]
        "06:22:b0:98:94:0b" -> "02:c7:5f:09:af:0f" [label="HNA"]
        subgraph "cluster_06:22:b0:98:94:0b" {
                "06:22:b0:98:94:0b" [peripheries=2]
        }
        "06:22:b0:98:87:f9" -> "06:22:b0:98:94:0b" [label="1.20"]
        "06:22:b0:98:87:f9" -> "06:22:b0:44:c6:59" [label="1.71"]
        "06:22:b0:98:87:f9" -> "00:13:e8:50:c0:ff" [label="1.32"]
        "06:22:b0:98:87:f9" -> "00:22:b0:98:87:f9" [label="HNA"]
        "06:22:b0:98:87:f9" -> "9e:03:d3:3e:3e:15" [label="HNA"]
        subgraph "cluster_06:22:b0:98:87:f9" {
                "06:22:b0:98:87:f9" [peripheries=2]
        }
        "06:22:b0:44:c6:59" -> "06:22:b0:98:87:f9" [label="1.15"]
        "06:22:b0:44:c6:59" -> "00:13:e8:50:c0:ff" [label="1.28"]
        "06:22:b0:44:c6:59" -> "06:22:b0:44:94:5d" [label="1.80"]
        "06:22:b0:44:c6:59" -> "46:b4:01:60:f6:57" [label="HNA"]
        "06:22:b0:44:c6:59" -> "00:22:b0:44:c6:59" [label="HNA"]
        subgraph "cluster_06:22:b0:44:c6:59" {
                "06:22:b0:44:c6:59" [peripheries=2]
        }
        "00:13:e8:50:c0:ff" -> "06:22:b0:98:87:f9" [label="1.3"]
        "00:13:e8:50:c0:ff" -> "06:22:b0:98:94:0b" [label="1.28"]
        "00:13:e8:50:c0:ff" -> "06:22:b0:44:c6:59" [label="1.36"]
        "00:13:e8:50:c0:ff" -> "06:22:b0:44:94:5d" [label="1.53"]
        "00:13:e8:50:c0:ff" -> "2e:bb:47:5b:b1:5e" [label="HNA"]
        subgraph "cluster_00:13:e8:50:c0:ff" {
                "00:13:e8:50:c0:ff" [peripheries=2]
        }
        "06:22:b0:44:94:5d" -> "06:22:b0:98:87:f9" [label="1.0"]
        "06:22:b0:44:94:5d" -> "06:22:b0:98:94:0b" [label="1.89"]
        "06:22:b0:44:94:5d" -> "06:22:b0:44:c6:59" [label="1.28"]
        "06:22:b0:44:94:5d" -> "00:13:e8:50:c0:ff" [label="1.49"]
        "06:22:b0:44:94:5d" -> "00:22:b0:44:94:5d" [label="HNA"]
        "06:22:b0:44:94:5d" -> "da:ef:64:a7:33:a7" [label="HNA"]
        subgraph "cluster_06:22:b0:44:94:5d" {
                "06:22:b0:44:94:5d" [peripheries=2]
        }
}
  Originator     (#/255)           Nexthop [outgoingIF]:   Potential nexthops ... [B.A.T.M.A.N. adv 0.2.1-beta, MainIF/MAC: wlan0/00:13:e8:50:c0:ff]
06:22:b0:98:87:f9  (252) 06:22:b0:98:87:f9 [     wlan0]: 06:22:b0:98:87:f9 (252) 06:22:b0:98:94:0b (232) 06:22:b0:44:94:5d (232) 06:22:b0:44:c6:59 (229)
06:22:b0:98:94:0b  (249) 06:22:b0:98:94:0b [     wlan0]: 06:22:b0:98:94:0b (249) 06:22:b0:44:94:5d (217) 06:22:b0:98:87:f9 (235) 06:22:b0:44:c6:59 (234)
06:22:b0:44:c6:59  (246) 06:22:b0:44:c6:59 [     wlan0]: 06:22:b0:44:c6:59 (246) 06:22:b0:44:94:5d (221) 06:22:b0:98:94:0b (229) 06:22:b0:98:87:f9 (225)
06:22:b0:44:94:5d  (242) 06:22:b0:44:94:5d [     wlan0]: 06:22:b0:44:94:5d (242) 06:22:b0:98:94:0b (225) 06:22:b0:98:87:f9 (212) 06:22:b0:44:c6:59 (227)
sh-4.1#
-----------------------------------------------------------------

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.

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.

I'm also attaching a capture on the laptop's wifi interface while
I had been sending ping-floods to ensure that the tq-values should be
changing frequently (which is not the case according to the
vis-server-output).

Cheers, Linus

[-- Attachment #1.2: vis-series2.cap --]
[-- Type: application/cap, Size: 27431 bytes --]

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

             reply	other threads:[~2010-03-09 23:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-09 23:03 Linus Lüssing [this message]
2010-03-11 16:38 ` [B.A.T.M.A.N.] [PATCH] batman-adv: Fixing wrap-around bug in vis Linus Lüssing
2010-03-11 17:14   ` Linus Lüssing
2010-03-11 21:19   ` Linus Lüssing
2010-03-11 21:41     ` Linus Lüssing
2010-03-11 22:06     ` Sven Eckelmann
2010-03-11 22:33       ` Sven Eckelmann
2010-03-11 23:04         ` Sven Eckelmann
2010-03-12  0:09           ` Linus Lüssing
2010-03-12  7:45             ` Andrew Lunn
2010-03-12  9:04             ` Sven Eckelmann
2010-03-12 15:16               ` Sven Eckelmann
2010-03-12 19:09                 ` Sven Eckelmann
2010-03-14 15:46                   ` Linus Lüssing
2010-03-14 17:51                     ` Marek Lindner
2010-03-12 20:57       ` Simon Wunderlich
2010-03-12 21:06         ` Sven Eckelmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100309230308.GB30949@Linus-Debian \
    --to=linus.luessing@web.de \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox