From: Steve Newcomb <srn@coolheads.com>
To: b.a.t.m.a.n@lists.open-mesh.org,
Ben Greear <greearb@candelatech.com>,
smartwires@gmail.com
Subject: Re: Network stops passing traffic randomly
Date: Mon, 1 Jun 2020 22:05:04 -0400 [thread overview]
Message-ID: <174b4bab-d84e-899d-3ecf-34bfdccff4fd@coolheads.com> (raw)
In-Reply-To: <20200529001302.832.66710@diktynna.open-mesh.org>
On 5/28/20 8:13 PM, smartwires@gmail.com wrote:
> Steve, I am also using ap with a QCA9558 SOC and Also using ath10k-firmware-qca988x . I have also considered using adhoc.
I think I discovered something yesterday that explains everything, and
it's very reproducible. The mesh mode in the QCA firmware works
reliably in the lab and in the field, but only when there are 3 or fewer
nodes. If I add one more node, the mesh will completely fail, either
immediately or within a few hours. If the nodes are strung out in a
daisy chain, failure is usually, but not always, delayed for a while,
and the links break in a piecemeal fashion, one at a time. If the nodes
are close enough to each other, total failure occurs quite quickly. I
surmise that the 802.11s implementation in the QCA driver was not tested
with more than 3 nodes, or perhaps it wasn't designed to support more
than 3 nodes. Sigh.
Sven, I think this epiphany obviates the need for your test (which I
still haven't figured out how to execute in the field), but I'll return
to that effort if you think I should.
So in the end, unless I replace the hardware throughout the neighborhood
with far more expensive hardware, I must find a way to use Ben's driver,
or to have no mesh network with more than 3 nodes in it.
next prev parent reply other threads:[~2020-06-02 2:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 8:35 Network stops passing traffic randomly smartwires
2020-05-25 8:43 ` Sven Eckelmann
[not found] ` <CAL3ir7+RWLrYOzjNQh1VwiKg1sxSgHZMwwqx=9xSfXFnFjE_KQ@mail.gmail.com>
2020-05-25 13:22 ` Sven Eckelmann
2020-05-25 13:45 ` Sven Eckelmann
2020-05-28 1:05 ` smartwires
2020-05-28 8:46 ` Sven Eckelmann
[not found] ` <cf75d66e-b0ac-632d-34e6-681ed9c6769d@coolheads.com>
2020-05-28 19:31 ` Sven Eckelmann
2020-05-28 21:17 ` Steve Newcomb
2020-05-28 19:03 ` Steve Newcomb
2020-05-28 19:19 ` Sven Eckelmann
2020-05-28 19:22 ` Ben Greear
2020-05-28 20:59 ` Steve Newcomb
2020-05-28 21:28 ` Ben Greear
2020-06-02 1:41 ` Steve Newcomb
2020-06-02 12:40 ` Steve Newcomb
2020-05-29 0:13 ` smartwires
2020-06-02 2:05 ` Steve Newcomb [this message]
2020-06-02 20:02 ` Ben Greear
2020-06-03 2:06 ` Steve Newcomb
2020-06-03 12:48 ` Ben Greear
2020-06-03 15:35 ` Steve Newcomb
2020-06-03 16:42 ` Ben Greear
2020-06-03 17:56 ` Steve Newcomb
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=174b4bab-d84e-899d-3ecf-34bfdccff4fd@coolheads.com \
--to=srn@coolheads.com \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=greearb@candelatech.com \
--cc=smartwires@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox