Hallo zusammen, ich musste erstaunterweise feststellen, dass ein PI4 (Buster) nicht mehr als 10 Clients in sein AP-Wlan reinlässt - vergibt also ab 10 aktiver Clients keine weiteren Leases (IP-Adressen) mehr. Dachte naiverweise bislang, dass die Subnetzgröße (bzw. die Festlegung in dnsmasq) über die maximale Anzahl der Leases entscheidet (also z.B. 254 Clients). Ganz eindeutig - es geht hier nicht um die verfügbare kumulierte Bandbreite oder Durchsatz oder Latency. Vielmehr wird der 11. Client und alle nachfolgenden erst recht - auch wenn kein Durchsatz - ohne weiteren Hinweis abgewiesen ...! Dass diese Max Beschränkung auf 10 beim Mobile Tethering Standard ist, wusste ich, hatte aber angenommen, dies sei eine Vorsichtsmassnahme / Vorgabe der Telcos. Aber offensichtlich geht es wohl mehr um WiFi Driver-Parameter, die vom Hersteller des Chips vorgegeben werden. Nun suche ich einen Accesspoint (Router), der mindestens über 100 Clients IP-Adressen vergeben / anbinden kann. Bandbreite und Durchsatz sind nicht so wichtig, da es um IoT Anwendungen mit wenig Datenverkehr geht. Kann mir jemand Fabrikate / Typen empfehlen, die auf größere IoT Zahlen vom Hersteller empfohlen werden / spezifiziert werden ? Ach ja - 802.1x muss der AP unbedingt unterstützen. Danke im Voraus!
Hendrik L. schrieb: > ich musste erstaunterweise feststellen, dass ein PI4 (Buster) nicht > mehr als 10 Clients in sein AP-Wlan reinlässt Das wundert mich auch. Normalerweise wird in der IT in Binärzahlen limitiert, also 16 als Maximum.
Im Prinzip können das alle professionellen oder semi professionellen APs. Mein Favorit ist Ubiquiti. Z.B. Unifi Ubiqiti Wifi 6 Pro kann 300+ Clients.
Michael H. schrieb: > Mein Favorit ist Ubiquiti. Z.B. Unifi Ubiqiti Wifi 6 Pro kann 300+ > Clients. Klare Empfehlung! F. F. schrieb: > https://www.tp-link.com/de/business-networking/omada-sdn-access-point/eap245/v3%20(einzelpackung)/#specifications Deren Software sieht der von Ubiquiti erstaunlich ähnlich, sogar die Symbole und so. Ich will nicht unterstellen, dass da nachgebaut wurde, vielleicht wurden da auch Lizenzen verkauft oder die Firmen kooperieren, schön wenn es mehr davon gibt! Die Zeiten in denen man eine teure Hardware als Controller kaufen musste (Aruba) sind schon lange vorbei.
:
Bearbeitet durch User
Gustl B. schrieb: > Michael H. schrieb: >> Mein Favorit ist Ubiquiti. Z.B. Unifi Ubiqiti Wifi 6 Pro kann 300+ >> Clients. > > Klare Empfehlung! > > F. F. schrieb: >> > https://www.tp-link.com/de/business-networking/omada-sdn-access-point/eap245/v3%20(einzelpackung)/#specifications > > Deren Software sieht der von Ubiquiti erstaunlich ähnlich, sogar die > Symbole und so. Ich will nicht unterstellen, dass da nachgebaut wurde, Naja, ich denke schon, dass das Ubiquiti Pate stand. Was ein Unterschied noch ist: Die EAP von TPLink kann man sowohl mit dedizierter externer Software als auch dezentral (also lokal auf dem AP) steuern. Das war für mich der ausschlaggebende Grund. Die Software läst sich auf diversen Systemen hosten. Ich mache aktuell den Fehler, dass ich das ab und zu starte auf meiner windowskiste. Werde ich aber bald auf eine raspb. oder sowas auslagern.. mal sehen. Im Moment tut es was es soll :-) Bei Ubiquity (ich kriege die richtige Schreibweise nie hin..) geht das nur dezentral. Meine Beobachtungen sind diese und darum hatte ich mich für TPLink entschieden: Ubiquity hat manchmal seltsame Updates, über die sich die Nutzer manchmal ziemlich aufregen. Sollte man einfach mal recherchieren.. Generell wird für Ubiquity ziemlich geworben auf youtube reviews, etc. Eine gewisse Stabilität scheinen sie zu haben oder werden gut bezahlt :-) Achso, was bei beiden geht, aber ich niemals machen würde: Die Steuerung beim Hersteller hosten. Die APs beider Hersteller sind für Firmen/Behörden gedacht und können viel an Masse/Benutzer abhaben. Wenn das nicht gebraucht wird, kriegt man das kostengünstiger hin: Eine alten Router nehmen und openwrt (o.ä.) draufspielen und fertig. Ich würde Ubi oder die Aps von TPLink nur nehmen, wenn ich viele APs auf einer Oberfläche administrieren möchte. PoE sollte man sich auch mal ansehen. Geht auf beiden. Ansonsten, wenn Du tief in die Materie einsteigen möchtest, beide APs sind auf openWRT(o.ä.) umstellbar, Details bitte selber nachsehen. Wobei ich das bei den Geräten unnötig finde. Beide haben sehr viele Einstellungsmerkmale. Und ein tipp für Bitfriemler: Mikrotek.
:
Bearbeitet durch User
Hendrik L. schrieb: >… > Nun suche ich einen Accesspoint (Router), der mindestens über 100 > Clients IP-Adressen vergeben / anbinden kann…< Also ein Router hat mit einem Accesspoint nun erst mal gar nichts zu tun ( auch wenn umgangssprachlich eine Kombination aus Router und AP, so fälschlicherweise bezeichnet wird ) Ob nun Clients eine dynamische Adresse von einem DHCP Server zugewiesen wird - oder auch nicht - hat ebensowenig mit einem Router zu tun. Wenn es solch eine komische Einschränkung an Deinem AP wirklich geben sollte, stellt sich mir die Frage, weshalb Du bei 11 Clients nicht einfach mit statischen IP‘s arbeitest - oder nicht auf IPv6 wechselst
Walter K. schrieb: > Hendrik L. schrieb: >>… >> Nun suche ich einen Accesspoint (Router), der mindestens über 100 >> Clients IP-Adressen vergeben / anbinden kann…< > > Also ein Router hat mit einem Accesspoint nun erst mal gar nichts zu tun > ( auch wenn umgangssprachlich eine Kombination aus Router und AP, so > fälschlicherweise bezeichnet wird ) > > Ob nun Clients eine dynamische Adresse von einem DHCP Server zugewiesen > wird - oder auch nicht - hat ebensowenig mit einem Router zu tun. > > Wenn es solch eine komische Einschränkung an Deinem AP wirklich geben > sollte, stellt sich mir die Frage, weshalb Du bei 11 Clients nicht > einfach mit statischen IP‘s arbeitest - oder nicht auf IPv6 wechselst Habe nur einen Teil hier berichtet - habe auch statische Adressen probiert > 10 Knoten (evtl. sogar nur > 8 ) werden vom Raspi gleichermassen abgewiesen (wie auch bei Smartphones im Tethering Mode). Problem ist im Internet bekannt ... https://github.com/raspberrypi/linux/issues/3010 ... ist eine Beschränkung im WiFi Driver Management - nicht ein Problem im OS. Habe diesen geordert https://eu.store.ui.com/products/unifi-ap-6-lite ... um erste Erfahrungen in der LAB-Phase für einen PoC zu sammeln. Später wrid dann optimiert (preislich / Anpassung an den echten BEdarf). Vielen Dank an Alle für Eure guten Hinweise - habt mir sehr geholfen. Gruesse
Hendrik L. schrieb: > Nun suche ich einen Accesspoint (Router), der mindestens über 100 > Clients IP-Adressen vergeben / anbinden kann. Das mit des IPs wurde ja schon geklärt. Andere Baustelle. APs begrenzen aufgrund interner Ressourcen die Anzahl gleichzeitig angebundener Clients. Das kann beispielsweise bei den Cisco Aironets für Business Einsatz bei 200 liegen. Diese Größenordnung auszureizen wird aber nicht empfohlen. Ein AP für den privaten Einsatz kann auch schon auf 10-15 begrenzen.
F. F. schrieb: > Generell wird für Ubiquity ziemlich geworben auf youtube reviews, etc. > Eine gewisse Stabilität scheinen sie zu haben oder werden gut bezahlt > :-) Das ist eben das Apple unter den Netzwerkfirmen. Nein ohne Scheiß, siehe https://en.wikipedia.org/wiki/Robert_Pera .
Gustl B. schrieb: > Das ist eben das Apple unter den Netzwerkfirmen. Apples Preisstruktur hat er aber nicht übernommen. Wenn du es teuer willst, nimm Cisco. ;-)
wieviele Clients müssen es den sein, in dem verlinktem Beitrag steht folgende Lösung. After 10 days of very thorough testing, it seems the IIAB default should be to... drop these 3 files into /lib/firmware/brcm : (for most all installs onto RPi, unless the implementer chooses to override this default in /etc/iiab/local_vars.yml) http://d.iiab.io/packages/brcmfmac43455-sdio.bin_2015-03-01_7.45.18.0_ub19.10.1 (477 KB, allows 32 WiFi connections to RPi 3 B+ & RPi 4) http://d.iiab.io/packages/brcmfmac43430-sdio.bin_2018-09-11_7.45.98.65 (388 KB, allows 30 WiFi connections to RPi Zero W & RPi 3) http://d.iiab.io/packages/brcmfmac43430-sdio.clm_blob_2018-09-11_7.45.98.65 (7.1 KB, necessary for the file just above) Of course renaming them appropriately (removing all date/version/OS suffixes). The hard part remains how to "lock" these 3 files in place, protecting the Access Point's ability to serve 30-32 clients — e.g. restoring these 3 files — if for example the OS's "unattended upgrades" (or any unexpected "apt update" or similar, due to an OS GUI popup or whatever reason) spontaneously overwrites any of these 3 files, at some future date. I like @jvonau's suggestion that we consider implementing some such protection logic in /sbin/test-wifi associated with wifi-test.service ...such that these 3 files are mandated on every boot (and if necessary checked for undesired/ongoing changes?) After auto-restoring the correct such firmware file(s), while a rare event, a 2nd reboot would of course be required — whether the reboot is automated or not — that being a design choice we should consider this week. Either way, every IT person knows: rebooting is often necessary, if at first you don't succeed... [So long as we avoid a worst-case "thrashing" scenario e.g. if some apt-like update keeps trying to re-upgrade firmware file(s) after every boot. However this seems unlikely/impossible, as apt should not try to re-update / re-upgrade on every boot, so I think we are safe here!]
Es geht um eine neuartige Anwendung im E-Mobility / Energy Supply Bereich, die ich mit einem Investor vermarkten werde. Der PoC (mit 10 Clients) läuft wunderbar - so habe ich den Investor gewonnen. Jetzt geht es um das MvP. Ca. 50 IoT Clients und 50 Smartphones (verteilt über 24 Stunden - jeweils für 30 Sekunden im WiFi eingeloggt) werden in dem Subnetwork aktiv sein. Daher ist die AP-Lösung die professionelle Richtung - alles Andere ist Gefriemel - auch wenn ich Geld spren würde. Die Zeit zum "Probieren" habe ich nicht. Es war einfach naiv von mir, anzunehmen, dass ~ 250 Clients lediglich über die AP Einstellungen im OS funktionieren (unabhängig von den WiFi Treibern) sollten. Vielen Dank und Gruesse
Ruf doch einfach mal bei ner Firma an, die APs und deren Controller herstellen oder vertreiben. Klar, bei Cisco und Co. bekämst Du bestenfalls irgendwelche Hotline-Deppen an die Leitung - aber nimm doch mal nen deutschen Hersteller: Lancom!
Also grundsätzlich ist das natürlich Unsinn, dass man bei Cisco bei irgendeiner Hotline rauskäme wenn man was kaufen will. Das ist ja nicht Vodafone wo Hotline und Vertrieb schonmal das Gleiche sind. Dass die im Vergleich zu Mid-Range-Produkten schweineteuer sind steht auf nem anderen Blatt, und das würde ich nicht bestreiten wollen. Da isses dann auch egal ob Aruba, Cisco, Extreme oder Ruckus draufsteht. Dafür sind die 100 Clients auch gleichzeitig kein Problem ;-) 100 Clients über 24h verteilt für je 30 Sekunden ist hingegen ne ganz andere Kragenweite. Da p***elt der AP die meiste Zeit im Leerlauf rum. Selbst wenn dann mal 20 auf einen Schlag kommen, bekommt das jeder anständige Midrange-AP auf die Kette. Man bemerke dass ich nicht von Router sondern immer nur von Accesspoint schreibe. Alles was nach der Authentifizierung kommt bzw. dafür notwendig ist, muss das Netz entsprechend bereitstellen. Also für deine Anforderung mit 802.1x mal mindestens Router, DHCP, RADIUS. DNS wird meistens auch gebraucht werden. Lass die Finger von den billigen Chinakrachern a la TP-Link oder schlimmerem. Damit wirste nicht glücklich. Deine Applikation klingt ein bisschen als würde sie ggf. in die Fläche ausgerollt werden. In dem Fall guck dir mal Meraki an (gehört mittlerweile zu Cisco). Die machen Netzwerkdevices mit Management in der Cloud. Machen andere auch wie z.B: Ubiquiti. Meraki macht es aber Templatebasiert, also ziemlich leicht hoch zu skalieren. Normalerweise bin ich ja nicht der Verfechter der Cloud - aber für diese Anwendung ist das schon eine schicke Lösung die mal einen echten Vorteil hat: Man braucht vor Ort nur irgendeinen Internetzugang, jemand stöpselt das da dran, die Hardware meldet sich in der Cloud an, zieht sich die Config und es läuft. Eine kleine Version davon gibts auch als Meraki one für Endanwender oder Kleinstfirmen. Tip: Aus Erfahrung kann ich dir sagen; Smartphones und 802.1x ist Mist! Selbst wenn du deinem Radius nen öffentlich signiertes teures Zertifikat mitgibst: Die Geräte mit nem Apfel drauf kennen das für Webseiten, benutzen den Certificate Store aber nicht für die WLAN-Authentifizierung sondern fragen den User stattdessen ob er mit dem untrusted WLAN verbinden will. Zumindest was das vor zwei iOS Versionen noch so. Android kann damit umgehen. Oder auch nicht. Je nach Hersteller, Version und Baureihe. Den meisten Samsung-Devices fehlte z.b. die Option "Systemzertifikate verwenden" bei der Zertifikatprüfung. Die konnten den RADIUS also nicht validieren und es blieb nur "nur validieren" als Option. Und eine von den ganz ganzigen Billo-Kisten hatte nichtmal diese Option - man konnte nur "bitte Option auswählen" wählen. Na danke... Und die üblichen WiFi QR-Codes taugen auch nur für Zugänge mit PSK. Wenn deine Smartphones also nicht gerade managed Devices einer Firma sind, wirst du da wenig Spaß mit haben. Technisch geht es (fast immer), ist aber nennenswert Supportaufwand und der normale User kommt ohne Hilfestellung damit NICHT klar.
P. W. schrieb: > Alsois .... > ... > Deine Applikation klingt ein bisschen als würde sie ggf. in die Fläche > ausgerollt werden. > In dem Fall guck dir mal Meraki an (gehört mittlerweile zu Cisco). > Die machen Netzwerkdevices mit Management in der Cloud. Machen andere > auch wie z.B: Ubiquiti. > Meraki macht es aber Templatebasiert, also ziemlich leicht hoch zu > skalieren. Normalerweise bin ich ja nicht der Verfechter der Cloud - > aber für diese Anwendung ist das schon eine schicke Lösung die mal einen > echten Vorteil hat: Man braucht vor Ort nur irgendeinen Internetzugang, > jemand stöpselt das da dran, die Hardware meldet sich in der Cloud an, > zieht sich die Config und es läuft. > Eine kleine Version davon gibts auch als Meraki one für Endanwender oder > Kleinstfirmen. > > > Tip: > Aus Erfahrung kann ich dir sagen; Smartphones und 802.1x ist Mist! > Selbst wenn du deinem Radius nen öffentlich signiertes teures Zertifikat > mitgibst: Die Geräte mit nem Apfel drauf kennen das für Webseiten, > benutzen den Certificate Store aber nicht für die WLAN-Authentifizierung > sondern fragen den User stattdessen ob er mit dem untrusted WLAN > verbinden will. Zumindest was das vor zwei iOS Versionen noch so. > Android kann damit umgehen. Oder auch nicht. Je nach Hersteller, Version > und Baureihe. > Den meisten Samsung-Devices fehlte z.b. die Option "Systemzertifikate > verwenden" bei der Zertifikatprüfung. Die konnten den RADIUS also nicht > validieren und es blieb nur "nur validieren" als Option. > Und eine von den ganz ganzigen Billo-Kisten hatte nichtmal diese Option > - man konnte nur "bitte Option auswählen" wählen. > Na danke... > Und die üblichen WiFi QR-Codes taugen auch nur für Zugänge mit PSK. > > Wenn deine Smartphones also nicht gerade managed Devices einer Firma > sind, wirst du da wenig Spaß mit haben. Technisch geht es (fast immer), > ist aber nennenswert Supportaufwand und der normale User kommt ohne > Hilfestellung damit NICHT klar. Danke für die wertvollen 802.1x Tips! In der Tat habe ich bislang nur mit Android getestet - da geht's super gut. Ich dachte Apple hätte die Nase vorn ... aber bestätigt einmal mehr meine Meinung, dass Apple sein Geld nicht wert ist, wenn man objetiv (technisch) vergleicht - aber welcher TictToc Fan tut das schon ....! Sicherheitstechnisch ist die Sache nicht so kritisch, über Packet Filtering lasse ich nur ca. 10 Ziel - Adressen durch, stelle also lediglich einen total eingeschränkten (transparenten) Kommunikationskanal zur Verfügung - zu Payment Service Providern. Ich verhalte mich also wie ein Public Hot Spot - aber eben nur mit einem Use Case - Electronic Payment! Normales Internet wie z.B. Surfen, etc. gehr also nicht. Die PSPSs sorgen dann für die entsprechende Ende - zu Ende Sicherheit (mit Zwei Faktor etc.) - ansonsten würde ihr Geschäftsmodell "Payment über's Internet" nicht fliegen ...! Danke & Gruesse
Ob hier relevant ist mir unklar, aber der Vollständigkeit halber erwähnt: Bei Cisco wird nicht nur die Konfiguration der APs zentral gemanagt, sondern es besteht auch die Möglichkeit, den WLAN-Datenverkehr unabhängig vom jenem Transportnetz zu zentralisieren, in dem der AP steckt. Das ähnelt topologisch einem VPN-Stern auf Layer 2. Der WLAN-Traffic geht getunnelt über den WLAN-Controller. Das Netz, in dem der AP steckt, muss nur den Tunnel ermöglichen (Ansprechstelle per DHCP/DNS-Information), die WLAN-Clients bekommen mit diesem Netz keinen Kontakt. In Unternehmen mit vielen Aussenstellen kann das sehr nützlich sein.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Ob hier relevant ist mir unklar, aber der Vollständigkeit halber > erwähnt: Bei Cisco wird nicht nur die Konfiguration der APs zentral > gemanagt, sondern es besteht auch die Möglichkeit, den WLAN-Datenverkehr > unabhängig vom jenem Transportnetz zu zentralisieren, in dem der AP > steckt. > Genau! Deshalb ist dies auch z.B. wenn Rooming wichtig ist - unverzichtbar!
@Oliver: Jenau so macht man det. Mit dem Apple Configurator beim Massenrollout von Devices oder über ein MDM. Heißt ja auch schon WPA-Personal und WPA-Enterprise. Blöd nur wenn man jetzt den Fall , dass ein Personal Device in ein Enterprise-Network rein soll. Zum Beispiel weil man sich in einem nicht so gut aufgestellten Staat befindet wo der Mobilfunkempfang in der Halle echt mies ist und/oder Datenvolumen limitiert. Es geht, aber es ist halt deutlich komplizierter als "Ich geb nen PSK ein und bin drin". Mittlerweile gehen zwar individuelle PSK pro Endgerät. Ist aber auch nicht mit "Haken setzen und dann rennt das von allein" getan. @A.K. Das ist der erwähnte CAPWAP-Tunnel. (Technisch übrigens zwei UDP 5246 und UDP 5247 für Control und Nutzdaten) Ist nicht nur bei Cisco so sondern eigentlich bei allen großen Playern, da heißt das Kind ggf. anders. Ubiquiti kann das übrigens nicht; umgekehrt kann Cisco seit ein paar Jahren auch nen lokalen Outbreak. Nennt sich da FlexConnect und am Ende fallen die Daten einfach in einem VLAN direkt am AP raus und das kann man ganz normal auf Layer2 in seiner Infrastruktur verteilen. Bei Extreme gehts auch, da wüsste ich aber keinen tollen Namen für das Feature. Gedacht ist FlexConnect eben gerade für Außenstellen weil man den großen Batzen Internettraffic dann lokal raus schieben kann, statt ihn erstmal per VPN in der Firmenzentrale zu aggregieren und dann doch nur weiter zu routen. Da ja heute alles Cloud und Internet und sowieso ist, macht der Traffic der eh "nur nach draußen" muss schon einen relevanten Teil aus. Das Management-Interface muss natürlich weiterhin mit dem Controller sprechen können. @Walter K. Das Roaming auf WiFi-Seite ist erstmal unabhängig davon. Die Zusatzprotokolle gehen alle auf die Luftschnittstelle und assistieren dem Endgerät dabei möglichst elegant zu einem neuen AP zu springen. Wobei Roaming im WiFi immer noch ein "bitte bitte liebes Endgerät, willst du nicht lieber diesen anderen AP hier benutzen" ist. Im Mobilfunknetz ist das ein: "Du! Jetzt rüberspringen zur Basisstation X!". Voraussetzung dafür ist "lediglich" eine Controllerbasierte Lösung die die "Session" zwischen APs weiter reichen kann. Das funktioniert mit und ohne Tunnel. Sonst hieße jeder Wechsel auch automatisch Neuverbindung. Das ist dann wie wenn man in der Bude daheim nen Sack voll Plastikrouter verteilt die alle voneinander nichts wissen und nur mit gleicher SSID und PSK ausstrahlen. Kann man so machen. Ist dann halt sch... Dass die Kisten auf Ethernet-Seite dann mit dem Wechsel der APs von Switchport zu Switchport hüpfen ist in der Praxis kein Problem.
P. W. schrieb: > Internettraffic dann lokal raus schieben kann, statt ihn erstmal > per VPN in der Firmenzentrale zu aggregieren und dann doch nur weiter zu > routen So kriegt man zwar effizienteren Traffic, mogelt sich aber an der zentralen Firewall vorbei. Es legt nahe, dass man dann auch dezentral eine Firewall verwendet und es verlagert die Kosten dorthin.
:
Bearbeitet durch User
Ja nee, vorbeimogeln ist kein valides Netzkonzept. WiFi und Firewall müssen da schon zusammenspielen. In größeren Umgebungen wo das verschiedene Teams, Abteilungen oder gar Unternehmen sind, ist da natürlich etwas Abstimmungsbedarf vorhanden. Aber hey - bekanntlich steht das S in IoT für Security...
vielleicht wäre das, eine Lösung für dein Problem, da diesen Ding ja als Router fungieren soll werden hier bestimmt nicht solche Kastraktionen vorliegen. Man kann/muss sich nur ein WLAN Modul besorgen, also läßt sich das auch einfach tauschen oder wenn ein neuer Standart kommt. 5x GBit RJ45-Ports, HDMI 4k, 2x USB 3.1 Gen1 und Micro-USB,Speaker-Anschluß, Kopfhörer-Anschluß, SATA,, RTC, PCIe-Sockel (Mini PCIe) und M.2 für eine weitere SSD, 16 GByte eMMC, 2 GByte RAM https://www.golem.de/news/banana-pi-bpi-r2-pro-platine-mit-fuenf-ethernet-ports-fuer-den-selbstbau-router-2109-159402.html
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.