From: Christof Schulze <christof.schulze@gmx.net>
To: elektra <onelektra@gmx.net>
Cc: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] Fwd: Re: increasing BATADV_FRAG_MAX_FRAGMENTS
Date: Wed, 02 Jul 2014 19:25:59 +0200 [thread overview]
Message-ID: <2115088.IOMlxmsL1n@lappi> (raw)
In-Reply-To: <20140701112142.3c8ab7cd16f81b51da706026@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]
Hi
> > During an experiment it was found, that
> > BATADV_FRAG_MAX_FRAGMENTS=16 allows ~72 clients to be connected to
> > one single access point.
> > would you mind sharing some details regarding the experiments you
> > performed ? The reason for this question is that there is no 72
> > client limit we know of (unless fragmentation was disabled).
> you are very likely looking in the wrong direction. The number of
> clients allowed to connect to an AP is configurable and 72 is
> already way beyond what I would consider useful in real life – if
> your clients are actually supposed to be able to communicate unicast
> traffic.
> Since you are probably using OpenWRT for your tests, look at the
> configuration parameter maxassoc:
> http://wiki.openwrt.org/doc/uci/wireless
> I don't know the default that OpenWRT uses if you don't set it
> explicitly. But there is a default limit set somewhere (take a look
> at hostapd.conf) and you might have discovered that by pushing it to
> the limit. It might as well be the limitation of your WiFi driver /
> hardware, though.
Thank you for your response.
maybe it is indeed a little far-fetched to point at batman at first.
On the other hand - the investigation has to start somewhere.
From your feedback and from feedback on IRC I gathered the following
list of possible issues and things to look at:
* there might be an issue with not enough multicast-traffic being
allowed - hypothesis: The client could associate with the AP but
no IP was received.
* the bandwidth of the air (airtime) might be saturated.
* There might be a driver issue
If it is known that no more than 70 clients per device is sensible,
then we have to consider actually setting some limits and using
maxassoc.
Christof
--
() ascii ribbon campaign - against html e-mail
/\ against proprietary attachments
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
prev parent reply other threads:[~2014-07-02 17:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-30 22:07 [B.A.T.M.A.N.] Fwd: Re: increasing BATADV_FRAG_MAX_FRAGMENTS Christof Schulze
2014-07-01 9:21 ` elektra
2014-07-01 12:25 ` Jan Lühr
2014-07-02 17:25 ` Christof Schulze [this message]
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=2115088.IOMlxmsL1n@lappi \
--to=christof.schulze@gmx.net \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=onelektra@gmx.net \
/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