From: Christof Schulze <christof.schulze@gmx.net>
To: "b.a.t.m.a.n@lists.open-mesh.org" <b.a.t.m.a.n@lists.open-mesh.org>
Subject: [B.A.T.M.A.N.] Fwd: Re: increasing BATADV_FRAG_MAX_FRAGMENTS
Date: Tue, 01 Jul 2014 00:07:32 +0200 [thread overview]
Message-ID: <1543341.WcWe2c7VXj@lappi> (raw)
[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]
Dirk is not on this list, so I am forwarding the information of ihs
experiment.
---------- Forwarded Message ----------
Hi, Marek!
Please forward this as appropriate.
Am 30.06.2014 um 08:08 schrieb Marek Lindner <mareklindner@neomailbox.ch>:
> > 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).
I put a freifunk router with batman.adv in a room with 300 conference
participants (with about 2 WLAN clients p.p.) as an emergency network access
means for a failing venue network.
The batman client statistic showed a very untypical hard clip at 72/74 batman
clients and new wlan clients seem to time-out without any network traffic like
this:
Thu Jun 26 15:33:44 2014 kern.warn kernel: [15577.090000] net_ratelimit: 1121
callbacks suppressed
At the same time, I'm seeing a lot of these:
Thu Jun 26 15:31:54 2014 daemon.info hostapd: wlan0-1: STA b4:f0:ab:9b:b0:94
IEEE 802.11: associated (aid 7)
Thu Jun 26 15:32:54 2014 daemon.info hostapd: wlan0-1: STA b4:f0:ab:9b:b0:94
IEEE 802.11: disassociated
Thu Jun 26 15:32:55 2014 daemon.info hostapd: wlan0-1: STA b4:f0:ab:9b:b0:94
IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
There is no hostapd client limit configured and otherwise (as I understand it),
clients would be have been rejected and not time-out without access to the
DHCP-Server (only accessible via batman).
Unfortunately, that setup is no longer available for more testing.
Any ideas?
Dirk
--
() 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 --]
next reply other threads:[~2014-06-30 22:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-30 22:07 Christof Schulze [this message]
2014-07-01 9:21 ` [B.A.T.M.A.N.] Fwd: Re: increasing BATADV_FRAG_MAX_FRAGMENTS elektra
2014-07-01 12:25 ` Jan Lühr
2014-07-02 17:25 ` Christof Schulze
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=1543341.WcWe2c7VXj@lappi \
--to=christof.schulze@gmx.net \
--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 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.