Een access point meldt zich niet bij CAPsMAN

Je hebt een controller ingesteld, het CAP-script op het access point geplakt, en er gebeurt niets. Op het AP staat requesting..., op de controller verschijnen geen dynamische interfaces, en het AP zendt zijn eigen oude netwerk uit of helemaal niets.

Dit hoofdstuk gaat over het AP dat zich niet aanmeldt. Komt het AP helemaal niet op, ga dan naar Een apparaat op een PoE-poort komt niet op. Meldt het zich wel aan maar lopen clients niet lekker over, zie Clients blijven aan het verkeerde AP hangen.

De snelle controles, in deze volgorde

1. Luistert de controller? Op de router: /interface wifi capsman print. Goed antwoord: enabled: yes en bij interfaces de interface waar de CAPs vandaan komen. Op de legacy-stack is dat /caps-man manager print plus /caps-man manager interface print.
2. Wat zegt het AP zelf? /interface wifi cap print. Goed antwoord: enabled: yes met een ingevulde current-caps-man-address. Staat er requesting..., dan hoort het AP niemand. Legacy: /interface wireless cap print.
3. Heeft het AP een adres? Op de controller /ip dhcp-server lease print. Het CAP-script zet een DHCP-client aan op zijn eigen bridge; komt er geen lease, dan zit het AP op de verkeerde poort of op de verkeerde VLAN en kan het niets vinden.
4. Ziet de controller het AP? /interface wifi print op de controller. Goed antwoord: dynamische interfaces met namen als cap-<identity>-24ghz. Legacy: /caps-man remote-cap print.
5. Provisiont de controller? /interface wifi provisioning print. Goed antwoord: regels met een oplopende match-teller zodra een CAP zich meldt.
6. Wat staat er in de log? /log print where topics~"caps", aan beide kanten. Daar staat het verschil tussen "niet gevonden" en "gevonden maar geweigerd".

De gewone oorzaken, meest voorkomend eerst

Het AP en de controller zitten niet in hetzelfde broadcastdomein

Dit is verreweg de belangrijkste. Het CAP-script dat de tool genereert zet discovery-interfaces=bridgeLocal en vult geen adres van de controller in. Het AP zoekt de controller dus met broadcast op die bridge. Zit de controller achter een router, achter een VLAN-grens of aan de andere kant van een tunnel, dan vindt het AP hem nooit, hoe lang je ook wacht.

De oplossing is één regel die je zelf op het AP zet: /interface wifi cap set caps-man-addresses=10.0.0.1, met het beheeradres van de controller. Op de legacy-stack: /interface wireless cap set caps-man-addresses=10.0.0.1. De tool schrijft die regel niet.

De controller luistert op de verkeerde interface

Het veld Interface waarop CAPs de controller vinden staat standaard op het beheer-VLAN als je dat hebt. Komt het beheerverkeer van je APs untagged op de bridge binnen, dan hoort de controller de ontdekking niet. Zet de interface op wat de APs werkelijk gebruiken.

De poort naar het AP is geen trunk

Geef je SSIDs een VLAN, dan moeten die VLANs getagd over de poort naar het AP. De tool waarschuwt daar ook voor: De poorten naar de CAPs moeten trunk zijn met de SSID-VLANs tagged. Op het netwerkbord maakt een getekende kabel tussen twee apparaten die poort vanzelf trunk; zonder bord wordt hij geraden.

Het verkeerde pakket op het AP

De wifi-CAPsMAN praat alleen met APs die op het wifi-pakket draaien. Een cAP ac op het oude wireless-pakket hoort er niets van; die hoort bij de legacy-stack, of bij wifi-qcom-ac. Kies je in de tool de verkeerde stack, dan is er geen foutmelding, er gebeurt alleen niets.

De identity matcht niet

Vul je bij Alleen CAPs met identity die matcht bijvoorbeeld ^cap- in, dan wordt een AP dat anders heet niet geprovisioned, ook al is het netjes gevonden. Het CAP-script zet de identity op cap-01; geef elk AP een eigen naam, want twee apparaten met dezelfde identity zijn in het netwerk niet uit elkaar te houden.

Het AP stond niet op fabrieksinstellingen

Oude configuratie, een vast adres uit een ander bereik, of een bridge die er al was. Reset het AP, of houd de resetknop ongeveer tien seconden ingedrukt voor CAP-modus.

Wat de configurator hiervan weet

In het onderdeel CAPsMAN kies je de stack (wifi of legacy), het land, de SSIDs met beveiliging, wachtwoord, banden, VLAN en client-isolatie, de kanaalbreedtes, 802.11r, local forwarding bij legacy, de identity-regexp, de interface waarop CAPs de controller vinden, en of de eigen radio's van de router ook door de controller beheerd worden.

Naast het hoofdscript levert de tool een tweede script, Script voor de CAP-apparaten, dat je op elk access point plakt. Dat script maakt een bridge bridgeLocal, zet ether1 en ether2 erin, start een DHCP-client, en zet de CAP aan met broadcast-ontdekking op die bridge. Heeft jouw AP maar één poort, dan haal je de regel voor ether2 weg: de tool weet niet hoeveel poorten het AP heeft, want het AP is niet het apparaat waarvoor je genereert.

In een site met meerdere apparaten is er één extra controle: staat er een controller in de site terwijl andere apparaten de rol access point hebben, dan meldt de tool dat die APs als los access point zijn ingesteld en dat je het CAP-script van de controller moet gebruiken.

Niet gedaan: de controller een vast adres meegeven aan het CAP, controleren of het AP de controller kan bereiken, de identity per AP uniek maken, of nagaan welk pakket er op het AP draait. Bij de legacy-stack waarschuwt de tool wel dat WPA3 daar niet bestaat en dat je SSIDs WPA2-PSK worden.

Als het niet aan je router ligt

Een switch tussen controller en AP die broadcast filtert, een beheer-VLAN dat op die switch niet doorloopt, of een AP met een RouterOS-versie die te ver uit de pas loopt. De controller staat op upgrade-policy=suggest-same-version, maar hij kan geen pakket uitdelen dat hij zelf niet heeft.

Verder lezen: CAPsMAN, CAPsMAN over meerdere locaties en Wifi-plan.