From: Sven Eckelmann <sven@narfation.org>
To: umut deniz <umut.deniz@gmail.com>
Cc: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] Fwd: nodes start disappearing after a certain node count
Date: Mon, 25 Feb 2019 15:19:26 +0100 [thread overview]
Message-ID: <6182329.DCpKyEnyDW@bentobox> (raw)
In-Reply-To: <CAHh66V8VNnbZCHWOi9ppnKbqfo1PbqVV3vSP1wbyROidBpTRCw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]
On Monday, 25 February 2019 15:06:21 CET umut deniz wrote:
[...]
> Thank your for your swift reply and advice. As you said TI supports limited
> number of peers with its driver and hardware in mesh mode. According to TI
> documentation it is 32 nodes.
I think this is the number of nodes in a complete 802.11s mesh. This doesn't
mean that it supports these number of direct peers the driver can't even
represent more than 16 direct peers/links in its structures. I heard something
of 10 peers supported by the firmware when running in AP mode. Most likely
lower or equal in meshpoint mode.
And maybe it also needs some special peers to work correctly. Wouldn't be the
first firmware which needs such kind of hacks.
> The question bogging my mind is how could the
> < :#iw dev adhoc0 station dump > command return 6 active and plink established
> nodes (with inactive times around 80ms) while batman-adv's last-seen is
> increasing till timeout occurs on all neighbors and after timeout iw station
> dump still reports the same active stations (with inactive times around 80ms).
> Am I missing something to debug or a log to look in to or a configuration
> tied with batman-adv needed to be made.
If the last time increases, this means that the lower link doesn't do correct
broadcast anymore between the peers. The numbers you see in iw can be from any
kind of frame (there might be exceptions - check the ieee80211 subsystem for
details).
This can either be a bug in the TI firmware or driver or maybe this is their
expected behavior when going over a specific number of entries. But there is
nothing batman-adv can do when the broadcast doesn't work correctly.
B.A.T.M.A.N. IV's metric is build around the broadcast frames and also
B.A.T.M.A.N. V needs them for local discovery.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-02-25 14:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAHh66V8N6KCqGdxnMQpHTaqjLbfMwWyGrRvjZY+P20W3-UF4Hw@mail.gmail.com>
2019-02-24 20:48 ` [B.A.T.M.A.N.] Fwd: nodes start disappearing after a certain node count umut deniz
2019-02-24 21:22 ` Sven Eckelmann
2019-02-25 14:06 ` umut deniz
2019-02-25 14:19 ` Sven Eckelmann [this message]
2019-02-25 16:00 ` Linus Lüssing
2019-02-25 16:50 ` 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=6182329.DCpKyEnyDW@bentobox \
--to=sven@narfation.org \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=umut.deniz@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.