<p dir="ltr">Hallo Sven</p>
<p dir="ltr">Am 09.01.2016 12:58 nachm. schrieb "Sven Roederer" <<a href="mailto:freifunk@it-solutions.geroedel.de">freifunk@it-solutions.geroedel.de</a>>:<br>
><br>
> HAllo,<br>
><br>
> On 09.01.2016 12:33, Kaya wrote:<br>
> > am Rande des letzten c-base Treffens hatten wir uns unterhalten, wie man am besten verhindert, dass sich zu viele User (z.B. in einer NUK) mit einem AP verbinden und damit das Teil faktisch un-nutzbar wird - obwohl vielleicht in einer anderen (etwas entfernteren) Ecke noch ein AP mit Ressourcen steht.<br>
><br>
> Die erste Frage die ich da sehe, ist es der Kernel / WLan-treiber /<br>
> Wlan-chip der hier den Fehler verursacht? Oder ist es der<br>
> dnsmasq-prozess, der hier zu viele Clients verarbeiten soll und<br>
> überlastet wird / zu wenig Speicher findet?<br>
><br>
> Ein log-file wäre hier prima ...</p>
<p dir="ltr">Ich halte folgenden Ablauf für plausibel:<br>
- WLAN-Treiber verbindet mit jedem, der eine Verbindung haben möchte.<br>
- DHCP-Server schaut in seine Liste und stellt fest, dass er keine freie IP mehr hat</p>
<p dir="ltr">Der Client hängt erstmal eine Weile in den Timeouts und versucht es danach immer wieder, bis es irgendwann mal funktioniert. Das habe ich zumindest in der AfRA beobachten können. Auf die Idee, den AP zu wechseln, kommt mein Android in den ersten Minuten nicht.</p>
<p dir="ltr">+1 für "Blick ins Log", da müsste das für die betroffenen Client-MACs gut verfolgbar sein.</p>
<p dir="ltr">Beste Abhilfe dürfte sein, dass der AP nicht mehr Clients zulässt als er verarbeiten kann. Die Zahl der zulässigen Clients sollte auch immer etwas kleiner als die Zahl der vorhandenen IP-Adressen sein, wegen der Timeouts der DHCP-Leases. Das liefert IMHO immer das gewünschte Ergebnis, egal ob es mehrere SSIDs oder Roaming mit BATMAN und einen zentralen DHCP gibt. <br></p>
<p dir="ltr">Harald<br>
</p>