In vielen Gebäuden ist ein einzelner Access Point heutzutage nicht mehr ausreichend. Insbesondere in großen Büros sind zur Abdeckung aller Räume mehrere Hotspots nötig. Wie man diese unter MikroTik RouterOS mittels CAPsMAN zentral steuert, das erfahrt ihr im folgenden Beitrag.
Wer sich noch nicht mit RouterOS befasst hat, dem empfehle ich meine Einstiegs-Serie zu dem Thema, um eine Grundkonfiguration vorzunehmen. Im Folgenden gehe ich davon aus, dass der Router eine funktionierende Anbindung ans Internet samt Firewall hat und DHCP- sowie DNS-Server korrekt eingerichtet sind.
Die hier genannten Befehle sind mit RouterOS bis einschließlich Version 6.40.x getestet. Ab Version 6.41 ändert sich insbesondere die Konfiguration der Bridges, sodass die Kommandos ggf. angepasst werden müssen. Einen Überblick über die Neuerungen gebe ich in einem separaten Blogposting.
Das Konzept
Grundsätzlich kann man eine ausreichende WLAN-Abdeckung auch dann herstellen, wenn man mehrere Access Points auf unterschiedlichen Kanälen, jedoch mit gleicher SSID und Passwort konfiguriert. Nachteil daran ist jedoch, dass es allein am Client liegt, mit welchem WLAN er sich verbindet und der Übergang (Handover) zwischen den einzelnen Systemen nicht immer problemlos funktioniert.
Das hier beleuchtete Konzept sieht eine Unterteilung in den eigentlichen Manager (CAPsMAN) und die einzelnen Access Points (CAP) vor. Die Access Points sind mehr oder weniger “dumme” Endgeräte, die auch komplett ohne Vorkonfiguration an den Manager angeschlossen werden können. Über diesen werden alle WLAN-relevanten Funktionen und Parameter konfiguriert. Die Verbindung läuft dabei auf Layer2-Ebene ab, behelfsweise ist aber auch eine IP-basierte Anbindung via Layer3 möglich, beispielsweise über verteilte Standorte hinweg.
Wichtig zu wissen ist, dass man damit nicht sämtliche Einstellungen der Access Points vornimmt – die Konfiguration der Pakete, die Einrichtung der Firewall oder das Anlegen von Benutzern fällt gerade nicht in den Aufgabenbereich. Der Dienst ist ausschließlich für WLAN-relevante Funktionen verantwortlich, für die gleichzeitige Massenkonfiguration vieler Router gibt es andere Tools.
Ein auf CAP geschalteter Access Point sucht sich im Netzwerk einen entsprechenden Manager, erhält ein eigenes Zertifikat und seine WLAN-Einstellungen werden ab dann zentral verwaltet – eine manuelle Einstellung der WLAN-Parameter am Access Point ist nicht mehr möglich (siehe im Bild oben den Hinweis managed by CAPsMAN).
Standardmäßig wird sämtlicher WLAN-Traffic über den Master ausgeleitet (CAPsMAN forwarding) – das erhöht zwar unter Umständen die Netzwerklast, sorgt aber dafür, dass die Clients in der Regel ohne große Unterbrechung zwischen den einzelnen Access Points wechseln, da diese als ein einziges System erscheinen. Alternativ und in dieser Anleitung unberücksichtigt gibt es auch noch die Möglichkeit des Local Forwarding, bei der der Traffic auf jedem Access Point direkt ausgeleitet wird – das bietet sich beispielsweise bei verteilten Standorten an.
Einstellungen am CAPsMAN-Manager
Standardmäßig deaktiviere ich in meinem Setup ungenutzte Pakete. Auf dem Router, der als Manager fungieren soll, ist das wireless-Paket jedoch zwingend erforderlich, auch wenn das Gerät selbst gar keine eigenen WLAN-Module verbaut hat. Im Zweifelsfall hilft ein
/system package enable wireless
gefolgt von einem
/system reboot
um die Funktionalität wieder zu aktivieren. Anschließend muss eine Bridge zwischen den Access Points und der kabelgebundenen Internetverbindung angelegt werden, beispielsweise mit
/interface bridge add name=br-cap /interface bridge port add bridge=br-cap interface=ether2
Existiert eine Bridge, fordert RouterOS grundsätzlich, dass alle Dienste darauf und nicht mehr auf das entsprechende ether– oder wlan-Interface gebunden werden. Am sichersten geht das bei eingeschaltetem Safe Mode beispielsweise mit folgenden Befehlen:
/ip dhcp-server set interface=br-cap [find interface=ether2] /ipv6 dhcp-server set interface=br-cap [find interface=ether2] /ip address set interface=br-cap [find interface=ether2] /ipv6 address set interface=br-cap [find interface=ether2] /ipv6 nd set interface=br-cap [find interface=ether2] /tool mac-server mac-winbox set interface=br-cap [find interface=ether2]
Obige Befehle eignen sich für meine Grundkonfiguration – je nach Einstellung müssen auch noch andere Dienste entsprechend angepasst werden. Auch die Firewall muss überarbeitet werden, da RouterOS die ether-Regeln bei Vorhandensein einer Bridge automatisch als ungültig markiert. Die folgenden zwei Zeilen können dabei helfen:
/ip firewall filter set in-interface=br-cap [find invalid] /ipv6 firewall filter set in-interface=br-cap [find invalid]
Die Firewall sollte unbedingt händisch überprüft werden, um keine deaktivierten oder ungültigen Regeln im Systen zu haben – der oben genannte Befehl ist zugegebenermaßen ein sehr krüder Workaround, der durchaus auch mehr kaputtmachen kann als er repariert!
Danach sind die grundsätzlichen Voraussetzungen für CAPsMAN geschaffen. Wie eingangs schon erwähnt, arbeitet das System auf Basis von Zertifikaten. In Teil 2 meiner Einsteigs-Serie bin ich bereits auf die grundlegende Funktionsweise eingegangen – nun möchte ich zusätzlich eine neue Zertifizierungsstelle (CA) anlegen, um die Zertifikate fürs WLAN besser verwalten zu können. Das geht mittels:
/certificate add name="CAPsMAN CA" common-name="CAPsMAN CA" key-usage=key-cert-sign,crl-sign key-size=2048 days-valid=3650 /certificate add name="CAPsMAN" common-name="CAPsMAN" key-size=2048 days-valid=3650 /certificate sign "CAPsMAN CA" name="CAPsMAN CA" :delay 5s; /certificate sign "CAPsMAN" ca="CAPsMAN CA" name="CAPsMAN" /certificate set "CAPsMAN CA" trusted=yes
Die Zeile mit :delay 5s; ist ein Workaround, denn wenn die Zertifikatserstellung im Skript zu lange dauert, dann quittiert RouterOS dies sonst mit einer Fehlermeldung beim Abarbeiten der weiteren Schritte.
Auf Basis dieser Zertifikate wird nun die eigentliche Instanz eingerichtet:
/caps-man manager set enabled=yes certificate="CAPsMAN" ca-certificate="CAPsMAN CA" /caps-man manager interface set [find] forbid=yes /caps-man manager interface add interface=br-cap disabled=no
Damit der Manager auch über die IP-Ebene auf Layer3 erreichbar ist, muss letztendlich noch die Firewall angepasst werden. In meinem Setup geht dies mit:
/ip firewall filter add chain=input action=accept in-interface=br-cap protocol=udp src-port=5246,5247 comment="accept CAPsMAN->LAN" place-before=[find comment="accept WinBox->LAN"] /ip firewall filter add chain=input action=accept in-interface=br-cap protocol=udp dst-port=5246,5247 comment="accept LAN->CAPsMAN" place-before=[find comment="accept WinBox->LAN"] /ipv6 firewall filter add chain=input action=accept in-interface=br-cap protocol=udp src-port=5246,5247 comment="accept CAPsMAN->LAN" place-before=[find comment="accept WinBox->LAN"] /ipv6 firewall filter add chain=input action=accept in-interface=br-cap protocol=udp dst-port=5246,5247 comment="accept LAN->CAPsMAN" place-before=[find comment="accept WinBox->LAN"]
Auch hier wieder der Hinweis, dass die Firewall unbedingt händisch überprüft werden sollte!
Bevor jetzt jedoch die Access Points angebunden werden, muss noch ein so genanntes Konfigurationsset zu Provisionierung erstellt werden. Einen Überblick über die möglichen Einstellungen erhält man am einfachsten über die Weboberfläche oder mittels WinBox. Eine gute Basis sind folgende Einstellungen:
/caps-man configuration add name="buero" mode=ap ssid="Buero WLAN" country="germany" channel.band=2ghz-b/g/n channel.extension-channel=disabled datapath.bridge=br-cap datapath.client-to-client-forwarding=yes security.authentication-types=wpa2-psk security.encryption=aes-ccm security.group-encryption=aes-ccm security.passphrase="1234567890"
Das richtet ein Konfigurationsprofil namens “buero” mit folgenden Parametern ein:
- die SSID lautet Buero WLAN
- die Sendeparameter werden auf die deutschen Regularien angepasst
- der Access Point funkt im 2,4 GHz-Bereich mit 802.11 b/g/n
- der Extension Channel wird deaktiviert, denn in Gebieten mit vielen WLANs kann die Verbindung dadurch beeinträchtigt werden
- der Access Point wird auf die (vorhin angelegte) Bridge namens br-cap gebunden
- Verbindungen der Clients untereinander sind erlaubt (in öffentlichen WLANS, beispielsweise bei Hotels oder Gaststätten, sollte diese Funktion deaktiviert werden)
- als Verschlüsselung kommt WPA2-PSK mit AES zum Einsatz
- das Passwort lautet 1234567890 (das sollte natürlich unbedingt geändert werden!)
Dieses Konfigurationsprofil muss nun noch auf die einzelnen Access Points angewendet werden, was über die so genannte Provisionierung möglich ist, die anhand der MAC-Adresse des WLAN-Moduls erfolgt. Einem Access Point können auch mehrere Konfigurationsprofile zugeordnet werden, beispielsweise für 2,4 und 5 GHz oder für Gast-WLANs. Die Provisionierung erfolgt dabei über einen Befehl wie
/caps-man provisioning add radio-mac=XX:XX:XX:XX:XX:XX action=create-dynamic-enabled master-configuration="buero" name-format=prefix name-prefix=br-cap-ap1-
Damit wird:
- der MAC-Adresse XX:XX:XX:XX:XX:XX
- das Konfigurationsprofil buero zugewiesen
- und das CAP-Interface mit dem Präfix br-cap-ap1- versehen
Einstellungen an den CAP-Access Points
Grundsätzlich benötigen die Access Points gar keine Voreinstellung, um für den Betrieb gerüstet zu sein. Viele Endgeräte lassen sich per Tastendruck zur automatischen Suche eines Managers im Netz bewegen, beispielsweise indem man den Reset-Taster für 10 Sekunden betätigt.
Ich nehme dennoch gerne eine Grundkonfiguration vor, um beispielsweise nicht benötigte Pakete zu deaktivieren. Wichtig ist – darüber bin ich am Anfang selbst gestolpert – dass am Access Point keine Bridge eingerichtet sein sollte, wie sie im Standalone-Betrieb eines Hotspots zum Einsatz kommt. Je nach genutzter MAC-Adresse, die sich durch die Reihenfolge der hinzugefügten Bridge-Schnittstellen ergibt, führt das unter Umständen zu Netzwerkschleifen, die ein korrektes Funktionieren verhindern.
Das eigentliche Aktivieren der CAP-Funktionalität geschieht im laufenden Betrieb ganz einfach mittels
/interface wireless cap set enabled=yes interfaces=wlan1 certificate=request discovery-interfaces=ether1 lock-to-caps-man=yes caps-man-certificate-common-names="CAPsMAN" static-virtual=yes
Der Access Point wird angewiesen, das wlan1-Interface per CAPsMAN zu konfigurieren, ein Zertifikat anzufordern und die kabelgebundene Verbindung ether1 für den Kontakt zum Manager zu verwenden. Um die “Übernahme” durch einen anderen Manager zu verhindern, wird der Access Point zudem angewiesen, nur solche Zertifikate zu akzeptieren, die auf CAPsMAN lauten, dem weiter oben für den Manager vergebenen Namen. Analog kann der Befehl übrigens auch für wlan2 eingegeben werden, sofern der Access Points über mehrere Antennen bzw. Module verfügt.
Kurze Zeit später sollten im Log vom Access Point Hinweise auf die erfolgreiche Anbindung erscheinen. Das Log sieht man mittels
/log print where topics~"caps"
und die Ausgabe sieht beispielsweise so aus:
aug/25 18:54:26 caps,info CAP selected CAPsMAN meinrouter (XX:XX:XX:XX:XX:XX/4/0)
aug/25 18:54:26 caps,info CAP connected to meinrouter (XX:XX:XX:XX:XX:XX/4/0), CommonName ‘CAPsMAN’
aug/25 18:54:26 caps,info CAP joined meinrouter (XX:XX:XX:XX:XX:XX/4/0)
Ausblick
Geschafft! Der Access Point wird jetzt erfolgreich mittels CAPsMAN verwaltet. Das konfigurierte WLAN sollte nun auf allen entsprechend provisionierten Access Points verfügbar sein.
Das System beherrscht dabei noch weitaus mehr Funktionalität, beispielsweise das zentrale Updaten aller Access Points. Doch das ist ein Thema für einen weiteren Beitrag…
Servus Florian,
danke für den schnörkellosen Artikel.
Ich werde die Vorgehensweise die Tage mal testen, sobald meine Mikrotik Access Points angekommen sind.
LG
Heiko
Danke! :)
Ein kleiner Fallstrick aus der Praxis:
Ursprünglich hatte ich
create-enabledfür die Interfaces. Das bedeutet, dass die Provisionierung nur einmalig durchgeführt wird – spätere Änderungen werden also nicht mehr automatisch ausgerollt! Praktischer ist dacreate-dynamic-enabled, dann werden Änderungen in der Provisionierung auch direkt auf die Access Points verteilt.Ich habe den Beitrag entsprechend angepasst.
Mittlerweile (das Blogposting ist entsprechend aktualisiert) setze ich im 2,4 GHz-Bereich zudem die Option
channel.extension-channel=disabled. Der Extension Channel wird dadurch deaktiviert, denn in Gebieten mit vielen WLANs kann die Verbindung dadurch beeinträchtigt werden.Sehr hilfreich. Danke !
Danke für das Feedback! :-)
Danke für die wunderbare Anleitung. Ich habe Probleme mit der Provisionierung des lokalen wlan1 auf dem Gerät, auf dem auch CAPsMan läuft. Als Discovery Interface habe ich die lokale bridge ausgewählt. Das funktioniert leider nicht. Gibt es was spezielles zu beachten? Danke!
Versuch mal, das Discovery Interface auf ether1 zu stellen (bzw. den Port, an dem das Kabel zum CAPsMAN hängt) – geht’s dann?
Ich glaube, dass ich mich falsch ausgedrückt habe: Der cap und CAPsMAN sind in der selben Hardware, – also das WLAN Interface der CAPsMAN Hardware selbst. Damit gibt es ja kein Kabel sondern nur bridges etc…
Ich habe nun doch noch alle nicht kursiven Interfaces als Discovery Interfaces durchprobiert: Mit ether2-master-local kommt kein connection fail mehr im Log. Aber es erscheint trotzdem kein zusätzliches Cap Interface im CAPsMAN.
Hm, das ist eine gute Frage – auf derselben Hardware hab ichs noch nicht probiert, obwohl ich das eigentlich mal machen wollte. ;-) Ist denn im Log sonst noch etwas Verwertbares? Irgendwelche Fehlermeldungen, irgendwas bezüglich CAPsMAN, irgendwas bezüglich Bridges? Ein
/log print where topics ~"caps"zeigt dir ggf. die relevanten Einträge an.
Ich habe das ganze nun noch auf einer anderen, neuen CRS109 Hardware nachgespielt: Das gleiche Verhalten. Nach der Provisionierung erscheint der wlan1 zwar “managed by CAPsMAN”. Aber im CAPsMAN ist es nirgendwo zu finden. Im log ist leider auch nichts zu sehen, – der letzte Eintrag ist “CAP configuration changed by admin”, – nachdem ich eben cap am wlan1 aktiviert habe.
Irgendwie habe ich den Eindruck, dass das Provisioning nicht greift. Ich habe aber eigentlich die richtige MAC Adresse des lokalen interface übernommen (/interface wireless print). Die Provisioning Regel habe ich auch von einem funktionierenden externen CAP kopiert und geändert.
Ich hab das hier noch nicht probiert, grundsätzlich klingt aber alles richtig. CAPsMAN ist manchmal aber durchaus tricky, ich hatte mal viel Spaß, als ich versehentlich noch eine Bridge am Gerät hatte und dann doppelte Pakete bemäkelt wurden. :-)
Wenn du aber eine zweite Hardware da hast, probier doch mal, ob die grundsätzlich als CAPsMAN-Controller laufen würde. Wenn es vom externen Gerät auch nicht geht, dann liegt der Fehler woanders, das hilft zumindest, das Problem einzugrenzen…
Habe jetzt einen externen cap (einen mAP lite mit nur einem wlan und einem ethernet interface) als CAPsMAN konfiguriert und dorthin das wlan Interface provisioniert. Das geht!
Nun habe ich noch probiert, das wlan des mAP lite wiederum auf den neuen lokalen CAPsMAN zu hängen. Habe eine bridge mit ether1 und wlan1 gemacht und das Discovery Interface auch auf die bridge gesetzt: Das geht!
Warum sich also eine mAP lite selbst managen kann und ein RB2011 oder CRS109 das verstehe ich jetzt nicht.
Danke für die Rückmeldung!
Ad hoc verstehen tu ich das auch nicht. Aber du kannst ja mal die Konfiguration beider Systeme exportieren und dann vergleichen, ob es markante Unterschiede gibt. Ich vermute, dass es etwas mit der Bridge zu tun hat…
Also; jetzt läuft es auf allen Geräten, die ich getestet habe. Vor lauter Rumspielen habe ich in der Winbox teilweise Felder in der CAP Config leer gelassen ( z.B.: CAPsMAN Certicate Common Names) und das hat dann Probleme gemacht.
Also: Discovery Interfaces auf die bridge und CAPsMAN Adresses 127.0.0.1 dann sollte es klappen!
Danke für die Rückmeldung!
Hallo Florian!
Du schreibst in deinem Beitrag, dass lokal auf den AP keine Bridge mehr eingerichtet werden soll.
Können dann die lokalen LAN-Ports auf den AP nicht mehr verwendet werden?
lg
Alfred
Die Bridge zwischen WLAN-Interface und der entsprechenden LAN-Schnittstelle solltest du nicht einrichten. Was aber gehen sollte (ungetestet) ist, wenn du die anderen Interfaces in einer Bridge zusammenschaltest. Wenn du alle Interfaces als Bridge brauchst, z.B. um das Gerät als Switch und Access Point gleichzeitig zu nutzen, musst du (ebenfalls ungetestet) bei der Wahl der MAC-Adresse vorsichtig sein und idealerweise eine Admin-MAC nutzen, die sich nicht mit einer existierenden deckt. Das war das Problem bei mir, dass die Reihenfolge der Bridge-Ports “ungünstig” war und dadurch doppelte Pakete entstanden sind.
Erstmal vielen Dank für all die guten Anleitungen.
Ich habe bei mir nur die Lan-Schnittstellen in der Bridge. Aber trotzdem erscheint mir die gesamte Netzwerkgeschwindigkeit viel zu langsam zu sein. (habe aber auch eine ganz eigene Config im CapsManager und damit 7 Caps im Haus verteilt, wobei nicht alle direkt ein Lan-Kabel bekommen. Aber deswegen brauche ich die Lan-Bridge.)
Welche Reihenfolge der Bridge-Ports sind da “ungünstig”?
Oder, wie bekomme ich heraus, ob bei mir dadurch auch doppelte Pakete entstehen?
Es könnte daran liegen, dass der Traffic über die Bridge nicht mehr hardwarebeschleunigt läuft, das ist aber nur ein Verdacht.
Schau mal via
/log printin deine Logdatei, ob dort etwas mit “duplicate packets” oder ähnlichem steht.Hallo Florian,
genau hier hänge ich fest. Ich habe jetzt eine Cap AP mit funktionierender WLan Schnittstelle (Hotspot CaptivPortal). Aber die ETH 2-4 Ports bekomme ich nicht hinzugefügt. Hast Du hierzu ein kleines Howto?
Auf der ETH1 kommt die Anbindung auf den Caps-Manager. ETH2-4 möchte ich als weitere Schnittstelle für das CaptivPortal nutzen.
lg
Christian
Hast du denn eth2-4 zur Bridge dazugefügt? Das sollte eigentlich genügen :-)
Vielen Dank für den ausführlichen Artikel.
Könntest du den noch um das Thema “Kanäle” erweitern?
Wie konfiguriert man WLAN Kanäle auf den Accesspoints? Geht das zentrale über CAPsMAN? Kann man dort vorgeben welcher CAP auf welchem Kanal und mit wie viel Leistung funken soll?
Schau dir mal von der MikroTik MUM Europe 2018 in Berlin den Vortrag von Ron Touw an, der macht im Prinzip genau das – zuordnen von Kanälen, Frequenzen & Co. per CAPsMAN. Hilft dir das schon weiter? :-)
Die Layer 3-Firewallregeln sind übrigens entbehrlich, wenn CAPsMAN im selben Netzsegment ist. Ich habe sie bei mir wieder entfernt, Probleme gab es keine.
Hallo Florian,
sollte bzw. müsste vor der Aufnahme in den CAPsMAN nicht auf dem CAP das antenna-gain gesetzt werden?, um nicht im jeweiligen Land zu stark zu senden.
Ich bin der Meinung schon (Info über das anntenna-gain findet man in Datenblatt des CAP), dies eine der wenigen Einstellungen welche noch lokal auf dem CAP vorgenommen werden muss, bevor er zentral verwaltet wird.
Gruß
Ich glaube, dass CAPsMAN alle lokalen Einstellungen überschreibt, d.h. wenn, dann müsstest du Antenna Gain via CAPsMAN setzen. Ist nichts gesetzt, wird meines Wissens ein Standardwert benutzt.
Hallo Florian,
laut Doku CAPsMAN:
When an AP is configured to be controlled by CAPsMAN, configuration of the managed wireless interfaces on the AP is ignored (exceptions: antenna-gain,antenna-mode). Instead, AP accepts configuration for the managed interfaces from CAPsMAN.
Wenn die Werte nicht lokal auf dem AP gesetzt werden, sind die TX Werte zu hoch, da du den antenna-gain nicht berücksichtigst somit sendest du im jeweiligen Land zu stark.
In der Tat, das ist ein interessanter Aspekt, den ich so noch nicht gelesen hab. Ich hab gerade mal auf einem AP geschaut, der default für Antenna Gain scheint bei 0 dB zu liegen, müsste also wirklich noch korrekt eingestellt werden. Allerdings gelingt es mir gerade nicht, die Werte überhaupt zu ändern, egal ob ich im CAP Mode bin oder nicht. Im CAP Mode sehe ich eine Fehlermeldung, dass das Interface gemanaged wird, ohne CAP Mode ändert sich der Wert schlicht nicht. Liegt das evtl. an den mit 6.42.11 eingeführten Änderungen beim WLAN?
Ok, mein Fehler, ich habs gefunden. ;-) Folgendes hat bei mir funktioniert, am Beispiel des wAP ac
/interface wireless cap set enabled=no/interface wireless set [find] antenna-gain=2
/interface wireless cap set enabled=yes
Anzeigen kann man das Ganze dann per
/interface wireless print advancedHallo Florian,
wenn 2 Clients im gleichen Wlan miteinander reden sollen, ist datapath.clienttoclient zu setzen, doch leider funktioniert bei mir kein Miracast (Projizieren in Windows 10), hat du eine Idee für mich ? Ping und alles andere funktionieren.
Arbeitest du mit verschiedenen VLANs, oder ist alles in einem VLAN?
Hallo Florian,
was beinhaltet deine Grundkonfiguration für die AccessPoints?
Ich konfiguriere die Access Points mehr oder weniger komplett durch, so wie in der MikroTik-Serie beschrieben. Zum Schluss verbinde ich sie dann mit dem CAPsMAN. Wenn ich etwas Zeit habe, veröffentliche ich mein Konfigurationsskript. :-)
Hallo Florian,
besten Dank für deine Aussführung zu CAPsMAN, funktioniert auf Anhieb mit den Teilnehmern (Handy etc.).
Was allerdings nicht funktioniert ist, dass sich ein MikroTik hAP ac auf den CAP AP einwählt. Bzw. einwählen geht im Station Mode, allerdings kann ich keine Daten übertragen. Irgendwie scheint der Wireless Mode im eingewählten hAP ac nicht korrekt zu sein. Bevor ich den CAPsMAN nutzte, hatte ich immer Station Bridge eingestellt, da hat es wunderbar funktioniert.
Hast du hier eventuell eine Idee?
Danke und Gruß Denis
Hallo Denis, ich hatte CAPsMAN schonmal mit einem mAP lite als Client laufen, der sich eingewählt hat – ich hab die Konfiguration aber aktuell nicht zur Hand, da muss ich passen. Grds. sollte es aber funktionieren…
Hallo Florian, einwählen funktioniert bei mir auch, nur kann auch vom eingewählten hAP nicht ins Netz und auf die anderen Teilnehmer im LAN zugreifen. Alles Firewall regeln sind identisch wie davor. Kann es sein, da es am Mode des CAPsMAN liegt, der läuft ja nur im AP Mode, nicht im AP Bridge Mode.
Danke und Gruß Denis
Bei mir hat das problemlos funktioniert – grundsätzlich geht es also, bin mir nur leider nicht mehr sicher, welchen Modus ich genutzt habe… falls ich die alte Doku nochmal finde, geb ich Bescheid! :)