Archivi tag: wifi

Mikrotik – CAPsMAN la mia strada

Dopo diversi anni di attesa, sono finalmente riuscito a completare la configurazione della rete domestica ed a darle un aspetto definitivo.
Premessa: il mio fornitore di servizio è un WISP della zona, che lavora molto bene ed è piuttosto “sveglio” a rispondere alle esigenze dei clienti. Malgrado questo non consente all’utente finale di accedere alla CPE, per impostare rotte personalizzate e questo è un grande limite se si vuole mettere una VPN casa-ufficio. La soluzione che ho adottato è probabilmente sub-ottima, ma funziona e consente di coprire le mie esigenze.

Topologia vecchia (SX) e nuova (DX)

A sinistra la precedente topologia, basata sul router del WISP (una ottima cambium) ed uno switch HP gigabit. Tutti i nodi domestici sono collegati allo switch. Lo spazio di indirizzi è 192.168.1.0/24.
La nuova architettura di rete ha un forte vincolo: non possono rinumerare per via della presenza di sensori che hanno indirizzo IP hardcoded e non possono essere riprogrammati in tempi ragionevolmente brevi. La soluzione è stata quella di splittare lo spazio in due parti, lasciando lato WISP la parte “alta” della rete e segmentando la parte bassa con un router MIkrotik, in modo da non dovere rinumerare alcun nodo.
I servizi che prima erano rediretti dal router WISP ai nodi della rete, sono interamente presi in carico dal Mikrotik, che provvede ad inviarli ai server.

La parte interessante della rete è la infrastruttura Wireless: casa è grande e per coprire bene tutto il volume, ho deciso di installare 3 AP e di coordinarne il funzionamento con una access controller. A posteriori, avrei usato volentieri Unifi che ha molte più funzionalità nei suoi AP, ma alla fine ho un funzionamento decente anche con Mikrotik. Gli apparati sono due AP “hAP ac²”ed un “hAP ac³“. I primi due sono installati nei piani 0 ed 1, mentre il terzo al piano 2 e funge da nuovo router. Su quest’ultimo è anche in esecuzione il CAPsMAN, oggetto della discussione.

La configurazione di CAPsMAN non è difficile, una volta che se ne è capita la bizzarra architettura: si tratta di una serie di moduli che devono essere personalizzati, prima di giungere ad un configurazione che può essere esportata ai dispositivi. Sezioni gerarchicamente superiori (provisioning o configuration) possono sovrascrivere alcune sezioni di configurazione
In particolare:
Channels: configurazione della banda operativa dell’access point e delle particolarità per ogni singolo canale.
Datapaths: configurazione del modo in cui i dati sono consegnati in rete (local forward o tulle forward), della client isolation e della MTU.
Security Cfg: metodo di autenticazione ed autorizzazione dei client.
Access List: consentono di definire alcuni parametri, sulla base dei quali i client possono o non possono accedere alle risorse.
Rates: configurazione degli MCS e dei rate.

Le configurazioni specifiche fatte in queste sezioni sono poi raccolte in una “configurazione” che può personalizzare alcuni aspetti, o semplicemente aggregare quanto fatto fino ad ora. Le configurazioni sono poi “consegnate” agli AP attraverso il “provisioning”. Quest’ultimo è interessante in quanto consente di essere molto granulari: ad ogni AP una configurazione dedicata, sulla base del mac-address o del nome.
Nella configurazione mi sono basato sugli ottimi articoli del MUM:
CAPsMAN
CAPsMAN WiFi Layer1 / Layer2 Optimisation
Common MikroTik WiFi mistakes and how to avoid them
Build enterprise wireless with CAPsMAN
CAPsMAN Case Study Uldis Cernevskis MikroTik, Latvia

Con queste informazioni ho creato una configurazione di sicurezza valida per tutti gli AP. Poi ho creato delle configurazioni “rates” per rimuovere 802.11b dalla banda 2.4GHz e 802.11a dalla 5GHz. La configurazione si concretizza in due “voci”, come mostrato in figura.

Configurazione dei rates

La configurazione complessiva, consta di 6 entries che possono essere “lette” in questo modo:
2G4 CH01 configurazione che assegna la banda di funzionamento 2.4GHz, con un profilo di sicurezza SecProf_01 e rate 2G4Rates ma vincola la frequenza al canale numero 1.
2G4 CH6 analoga alla precedente ma frequenza vincolata al canale 6.
In questo modo, possono fare un “provisioning” bloccando la frequenza di lavoro dei singoli ap in modo da evitare sovrapposizioni ed avere un maggiore controllo sull’intero impianto. Il vantaggio di questo approccio è che modificando la configurazione sul CAPsMAN, questa si riflette sugli AP, senza richiedere intervento.

Le “configurazioni”

Il provisioning è effettuato sulla base del mac address della radio. Ci sono sicuramente modi migliori per farlo, ad esempio sfruttando il nome della radio stessa ma non sono riuscito ad ottenere i risultati attesi. Per ogni radio, viene definito un comportamento (create dynamic enabled) ed una configurazione di riferimento, in questo caso 2G4 CH01. Questo significa che alla radio identificata con questo mac, sarà associata una configurazione che la vincola a funzionare sul canale 1.
Notare la “identity” nel campo “name format”, questo parametro influenza il modo in cui saranno “nominate” le Cap Interfaces ed è oggetto di ulteriore configurazione.

Provisioning basato su MAC

Selezionando la voce “Remote CAP”, sono elencati tutti i sistemi che partecipano al CAPsMAN. Facendo doppio click su uno di essi è si accede ad una finestra che mostra diverse informazioni e consente di effettuare il “set identity”, ovvero di associare una label a piacere ad ogni radio. Io ho deciso di utilizzare il piano presso il quale è installato l’AP.

Impostazione della identità

Risultati:
i tre Ap lavorano su frequenze differenti sia a 5GHz che a 2.4GHz. Rimane da sanare una situazione relativa ad un sensore che richiede un AP dedicato. In tempi brevi spero di riuscire a configurare un “virtual AP” attraverso CAPsMAN in modo da sanare anche questa situazione. I livelli di segnale sono molto buoni. A 2.4GHz sono visibili 4 AP di cui, quello “inserito” sul canale 4 è in via di spegnimento.

AP 2.4GHz

In banda 5GHz, dal “letto” sono visibili 2 AP, ben differenziati in termini di potenza ricevuta.

Esp8266 – No WiFi Connection

Dopo l’allagamento della mia stazione meteo, ho deciso di riprogettare tutto il sistema. Ho quindi realizzato un circuito stampato in modo da abbandonare per sempre la realizzazione filata su mille-fori. Il PCB lo ho disegnato con Eagle e realizzato presso Millennium Dataware, come sempre. Ho dovuto correggere qualche piccolo errore derivante dalla poca attenzione e massima fretta nello sbroglio delle piste, ma tutto ha funzionato bene. Almeno dal punto di vista elettrico.

Nel momento in cui sono andato a ricaricare il firmware sulla scheda mi aspettavo un funzionamento “alla prima botta”. Invece il dispositivo si è bloccato nella fase di connessione all’access point, restituendo codice di errore “6” da WiFi.Status(). In pratica: nessuna connessione. Malgrado questo io sul’AP ero in grado di vedere il modulo come “autorizzato” o connesso. Per sbrigliare meglio questa matassa ho deciso di utilizzare un AP realizzato con una RouterBoard Mikrotik, in modo da potere approfittare delle funzionalità di logging.

Il codice che gestisce la connessione verso l’AP è il seguente:

Serial.println("");
Serial.println("WIFI INIT");
Serial.println("");
WiFi.macAddress(MAC_array);
for (int i = 0; i < sizeof(MAC_array); ++i){
sprintf(MAC_char,"%s%02x:",MAC_char,MAC_array[i]);
}
Serial.print("Unit Mac Address is: ");
Serial.println(MAC_char);
Serial.println("");
Serial.print("Connecting to ");

Serial.println(ssid);

// IP,DNS,GATEWAY,SUBNET
WiFi.mode(WIFI_STA);
WiFi.begin(ssid, password); //Gestione della connessione ad un AP
WiFi.softAP(ssidSA, passwordSA, 1, 1); //Gestione del SoftAP e hidden SSID
WiFi.setOutputPower(0); // Impostazione della potenza di uscita

while (WiFi.status() != WL_CONNECTED) {
Serial.println(WiFi.status());
delay(1000);
Serial.print(".");
}

Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());

Cercando una possibile soluzione in rete mi sono imbattuto in questo post, in cui si legge:

WL_CONNECTED is only returned if the wifi interface has connected an has IP address
in DHCP mode this means you got the IP form the DHCP server. in Static mode you have set the IP yourself.

Detto fatto: ho configurato la mia MikroTik per lavorare come dhcp server e per effettuare il NAT della rete WiFi verso la rete di casa e… funziona!

Nota bene, in caso l’assegnazione dell’IP sia statica, il codice deve essere modificato in questo modo:

IPAddress host(192,168,**,**); //used for socket,mysql,mqtt 
IPAddress ip_wifi(192,168,**,**);
IPAddress dns_wifi(192,168,**,**);
IPAddress gw_wifi(192,168,**,**);
IPAddress subnet_wifi(255,255,**,**);

void setup() {
  Serial.println("");
  Serial.println("WIFI INIT");
  Serial.println("");
  //WiFi Management
  Serial.print("Connecting to ");
  Serial.println(ssid);
   
   WiFi.mode(WIFI_STA);
   WiFi.config(ip_wifi,dns_wifi,gw_wifi,subnet_wifi);  
   WiFi.begin(ssid, password);     
   WiFi.softAP(ssidSA, passwordSA, 1, 1); 
   WiFi.setOutputPower(0);        
   
  while (WiFi.status() != WL_CONNECTED) {
    delay(1000);
    Serial.print(".");
  }

[DISPLAY_ULTIMATE_SOCIAL_ICONS]