[B.A.T.M.A.N.] Fwd: Re: increasing BATADV_FRAG_MAX_FRAGMENTS

[B.A.T.M.A.N.] Fwd: Re: increasing BATADV_FRAG_MAX_FRAGMENTS

[Christof Schulze]

[-- 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 --]

Re: [B.A.T.M.A.N.] Fwd: Re: increasing BATADV_FRAG_MAX_FRAGMENTS

[elektra]

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.

Cheers,
Elektra








-- 
Viral meme of radical freedom 
 
The fact that you talk in your head doesn't mean that you think. 
 
The best way to lose control over yourself is trying to control yourself. 
 
Most people experience themselves as a voice in their head, telling them 
 who they are, what they think and what they have to do. 
 
http://en.wikipedia.org/wiki/Meme 

Re: [B.A.T.M.A.N.] Fwd: Re: increasing BATADV_FRAG_MAX_FRAGMENTS

[Jan Lühr]

Hello,


Am 07/01/2014 11:21 AM, schrieb elektra:
> 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.

After a lively discussion on irc, I'd like to finalize this thread. To
summarize, where we are so far:

-> batman-adv is not restricted to 72 clients. Pre-2014 versions (which
have been used here), support > 200 non-clients in their tt-table.

-> Initially posted by g3ntleman on the Freifunk-KBU mailinglist, an
observation (why can we handle 72 clients), became a rumor (there might
be a limit in batman-adv), became a fact (we observed a limit in
batman-adv) - without any support.

-> G3ntlemans setup was not meant to be in experiment in a sane setting.
It was an emergency fix for a broken down conference wifi. Which -
nevertheless - showed some interesting findings. I hope, that we can
document this for future reference, but the relevance of the findings in
general is probably rather poor.

-> The aftermath of the discovery was motivated by the idea of running
an experiment at this year's FrOSCon. If you like to join us here,
you're welcome :-).

-> It's still unclear, what we observed in detail and we'll probably
never know for sure. The reason is simple: No measurements / logs were
taken and we cannot reproduce the setting.

-> To emphasis this: It's neither evident nor even probable that any
property of batman-adv is a bottleneck in this scenario.

-> The used setup was not meant to be suitable for a conference wifi or
even high density wifi coverage. It suffers from obvious design flaws.
G3ntlemen just remembered having his box with him, the moment the
conference wifi was down. There was not a single thought spent on
scaling issues here.

-> I don't know, if 72 clients on a single wifi channel is sane or not (
Ubiquity claims, that the can handle 100) - and - if pre 802.11n
experiences (aka gut feelings) are applicable. However, getting a gut
feeling is the idea for this year's FrOSCon. Thus: Join, if you're
interested.

I'd like to excuse for all anger, frustration or hassle generated by
this discussion, and, I'd like to thank marec and ordex for their
helpful comments. Keep calm, carry one and thanks for your commitment to
batman-adv.

Greetz, Jan

Re: [B.A.T.M.A.N.] Fwd: Re: increasing BATADV_FRAG_MAX_FRAGMENTS

[Christof Schulze]

[-- 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 --]