Modulo wifi ESP8266 IoT programmazione stand-alone (senza arduino)

L’ ESP8266 è un modulo wifi dalle dimensioni molto compatte che permette di aggiungere caratteristiche di connettività wifi ai progetti arduino based. La logica a 3,3v si interfaccia con una seriale. E’ possibile interagire mediante un set di comandi AT: impostazione SSID e password di rete, apertura è gestione di un socket TCP o UDP (lo stack TCP è incluso). Poichè l’ ESP8266 è dotato di CPU e di porte GPIO è possible interfacciarsi a sensori è attuatori senza disporre di arduino nel mezzo. E’ possiblie utilizzando l’ SDK riscrivere il firmware per gestire l’intera applicazione. La programmazione avviene in C ed esiste un API per gestire wifi, timer, GPIO ecc. Lo sviluppo è più complesso rispetto ad arduino. Questà è l’installazione dell’ SDKQuesto è il primo programma da comprendere è semplicemente un LED che lampeggia su una GPIO. Questo è un progetto più complesso che permette di capire la gestione del wifi e dei socket. Il tutto è relativamente complesso, almeno inizialmente, c’è da sbatterci la testa.

Annunci
Pubblicato in Senza categoria | 1 commento

Dinosauri, TTL 74XX & CMOS 4000, Microcontroller & co.

A volte il progettista anziano non vuole sentir parlare di aggiornare i propri progetti con le nuove tecnologie. Funziona da anni, quindi va bene così. Questa è la mia frustrazione del momento così ho deciso di sfogarmi con questo post. Spero vivamente di esporre solo scontatezze alle giovani leve. Nella progettazione digitale è notoriamente esploso l’utilizzo dei microcontrollori ma poichè alcuni si ostinano ancora a incastrare tra di loro flip flop e porte logiche voglio esporre i pro e i contro di questi due approcci. Il primo punto è la leggibilità dello schema elettrico. L’ implementazione di una soluzione con flip flop e porte logiche, ovvero con la logica sequenziale, richiede il più delle volte l’ interazione di molti IC interconnessi tra di loro anche per problematiche relativamente semplici. Molto spesso una soluzione digitale basata su microcontrollore non vede altro che il microcontrollore stesso. Dal punto di vista elettrico sono noti per esempio i limiti di corrente alle uscite dei dispositivi CMOS e TTL, inadatti finanche a pilotare un LED. I pin dei microcontrollori sono programmabili cioè lo stesso pin, può diventare sia un uscita che un ingresso, può essere configurato open collector, può diventare l’ingresso di un ADC o ancora l’ingresso o l’uscita di periferiche più complesse quali: UART, modulatori PWM, timer, ecc. Un microcontrollore rende un applicazione scalabile, poche modifiche hardware e qualche modifica del firmware permettono di migliorare semplicemente e in poco tempo un applicazione. Un circuito sequenziale è un mattone a se. La modifica di un circuito sequenziale è possibile solo nel caso si semplici modifiche è altrimenti più semplice, per modo di dire, la riprogettazione ex-novo. Memoria non volatile: un circuito sequenziale una volta spento, perde tutti gli stati e alla successiva accenzione non abbiamo modo di sapere che cosa era successo prima, inutile dire che buona parte dei microcontollori hanno una EEPROM interna. Il punto dolente dei sistemi a microcontrollore è nello sviluppo del firmware ma in questi tempi sei tagliato fuori dall’ essere un elettronico se non sei anche un discreto programmatore. Oppure un dinosauro.

Pubblicato in Senza categoria | Lascia un commento

Il Single board computer più economico: TP-LINK TL-WR710N e OpenWRT.

tp-wr710n

Il TP-LINK WR710N è un piccolo ed economico dispositivo con diverse funzionalità. Può essere usato come access point per condividere la connessione a internet disponibile su cavo ethernet in wifi. Può inoltre essere un usato come wifi repeater, dispone di una porta USB per condividere il contenuto di stick USB e poco altro ancora. La cosa interessante di questo dispositivo è la possibilità di installare OpenWRT, una distribuzione minimale linux creata proprio per router, switch, ecc. Un altra curiosità di questo dispositivo è che la CPU utilizzata è la stessa utilizzata nell’ Arduino Yùn ma quest’ ultimo dispone del doppio di RAM e del doppio di Flash. Con OpenWRT, il WR710N diventa un piccolo computer a tutti gli effetti quindi le possibilità di utilizzo aumentano notevolmente. Nel mio caso sono riuscito a creare un access point wifi che condivide la connessione a interenet della chiavetta USB HDSPA, opzione impossibile con il firmware originale. Bisogna considerare inoltre che, a differenza ad esempio di un Raspberry PI, il WR710N dispone già di alimentatore di rete interno, costa intorno ai 20 euro e si può spegnere brutalmente senza effetti collaterali. E’ chiaro che le risorse hardware sono molto più limitate di un Raspberry PI. L’ unica pecca, se vogliamo, è che per flashiare il dispositivo con il firmware OpenWRT bisogna quantomeno saper usare un saldatore e capirne qualcosa di elettronica, istruzioni in francese qui. Il prossimo progetto con il WR710N sarà la realizzazione di casse acustiche attive con funzionalità DLNA (UPnP audio renderer) utilizzando OpenWRT e Rygel , per eventuali problemi vedi qua.

Pubblicato in Senza categoria | Contrassegnato , , , , | 2 commenti

Reverse Tunnel vs FTP (vsftpd).

Ultimamente ho studiato molto il funzionamento dei tunnel con SSH. Nessun problema a forwardare una connessione HTTP o SSH. Con il protocollo FTP viene fuori il problema della connessione dati. La porta 21 infatti, accetta solo comandi dal client. Nel momento in cui il client richiede l’ invio o la ricezione di un file, i dati di questo vengono trasveriti mediante un’ altra connessione TCP/IP. Client e server possono mettersi daccordo su questa “connessione di servizio” in 2 modalità: attiva e passiva. In modalita attiva, il client FTP apre una porta in ascolto e dice al server FTP di stabilire la connessione dati collegandosi a questa porta (comando PORT). In modalità passiva il client chiede al server FTP a quale porta collegarsi per effettuare la connenssione per la trasmissione dei dati (comando PASV). Per maggiori dettagli vedi qui. Quindi per tunnellizzare un server FTP non è sufficiente forwardare la sola porta 21. Quello che si può fare è:

-Utilizzare la modalità passiva.

-Configurare il server FTP in modo che utilizzi, per le connessioni dati passive, un range di porte da noi stabilito (es. 20091-20100).

-Configurare il server FTP in modo da  forzare la risposta al comando PASV con l’ IP della macchina del demone SSH.

-Effettuare il port forwarding di tutte le porte in gioco (ovvero la 21 e il range 20091/20100) verso il server SSH mediante reverse tunnel.

Questa è la teoria, adesso faccio un esperimento nella mia piccola LAN. Nel mio caso il server SSH gira su un Banana PI e il suo IP è 192.168.1.205 mentre il server FTP vsftpd è installato su un Raspberry PI con IP 192.168.1.248 . Quello che voglio fare è collegare il mio laptop (192.168.1.119) al server FTP del Raspberry PI attraverso il Banana PI. Per configurare correttamente vsftpd sul Raspberry PI dovrò modificare il file /etc/vsftpd.conf

pasv_enable=YES
pasv_min_port=20091
pasv_max_port=20100
pasv_address=192.168.1.205

Adesso bisogna creare tanti reverse tunnel dal Raspberry PI (da dove gira il server FTP), per tutte le porte necessarie. Se per la porta di controllo possiamo specificare valori di porte diversi tra origine e destinazione, per i socket dati le porte di origine e destinazione dovranno avere necessariamente lo stesso valore.

ssh -Ng -R *:20021:localhost:21 pi@192.168.1.205 
ssh -Ng -R *:20091:localhost:20091 pi@192.168.1.205 
ssh -Ng -R *:20092:localhost:20092 pi@192.168.1.205 
ssh -Ng -R *:20093:localhost:20093 pi@192.168.1.205 
ssh -Ng -R *:20094:localhost:20094 pi@192.168.1.205 
ssh -Ng -R *:20095:localhost:20095 pi@192.168.1.205 
ssh -Ng -R *:20096:localhost:20096 pi@192.168.1.205 
ssh -Ng -R *:20097:localhost:20097 pi@192.168.1.205 
ssh -Ng -R *:20098:localhost:20098 pi@192.168.1.205 
ssh -Ng -R *:20099:localhost:20099 pi@192.168.1.205 
ssh -Ng -R *:20100:localhost:20100 pi@192.168.1.205 

Finito. Aprendo il client FTP sul mio laptop (192.168.1.119) andrò a impostare l’ host 192.168.1.205 e la porta 20021 per collegarmi di fatto al server FTP che invece gira sull’host 192.168.1.248 in ascolto sulla porta 21.

L’ inconveniente di questa tecnica è che bisogna creare dei tunnel a prescindere dall’ effettiva utilità e assicurarsi inoltre che questi tunnel non cadano. Naturalmente tutto questo può essere affinato per esempio utilizzando autossh e utilizzando la chiave pubblica del server FTP per l’autenticazione automatica al server SSH.

Pubblicato in Senza categoria | Contrassegnato , , , , , | Lascia un commento

Progetto irctunnel: collegare 2 host dietro NAT senza il port forwarding, over IRC.

Se ignoriamo le tecniche di TCP hole punching et similia, possiamo affermare che: tra 2 host dietro NAT, senza che almeno uno dei due host disponga di porte forwardate dal router, il collegamento tra i due è impossibile. L’ unica via sta nel disporre di un terzo host che può ricevere connessioni su porte in ascolto senza rotture ulteriori, che svolga il compito di “macchina nel mezzo”. Nella realtà si potrebbe ad esempio affittare un VPS oppure utilizzare il servizio ngrok. Nel caso del VPS questo ha inanzitutto un costo ma il punto centrale è che bisogna registrarsi e questo non lo vogliamo. L’ idea è sfruttare un server IRC che si offra come ponte tra i due host anzi tra i due client. E’ noto che i server IRC sono limitati a smistare dati alfanumerici e non dati binari ma vedremo come superare questo limite. Vediamo come funziona:

Diciamo che esistono 2 programmi: uno gira sul client 1 e l’altro sul client 2.

Il programma che gira su client 1 mette in ascolto una porta e contemporaneamente si collega a un server IRC e entra in un chan e avrà un proprio nick.

Il programma che gira su client 2 si collega allo stesso server IRC, ed entra nello stesso chan e avrà un altro nick.

Client 1 vuole stabilire una connessione su client 2 diciamo un collegamento SSH.

Client 1 lancia il client SSH specificando come host localhost e come porta la porta aperta precedentemente dal programma.

A questo punto il programma su client 1 comunica via IRC con il programma su client 2 e chattando in privato gli ordina di collegarsi in localhost al servizio SSH.

Il client SSH su client 1, inizierà a inviare dati al programma che gira in locale su client 1.

Il programma su client 1, codifica i dati ricevuti dal client SSH in base64 (alfanumerici) e gli invia mediante chat privata al programma su client 2.

I dati ricevuti dal programma 2 su client 2 verranno decodificati da base64 e verranno inviati al servizio SSH locale.

E così via.

Naturalmete bisognerà creare un protocollo over IRC ad hoc poichè i due programmi dovranno scambiarsi: i comandi, gli stati della connessione e naturalmente i dati. C’è da osservere che la codifica base64 appesantisce la comunicazione poichè per 3 byte binari ne dovranno essere inviati 4 in base64.

Aggiornamento del 06/01/2015.

Quest’ idea è già stata implemantata in python, questi sono i sorgenti.

Pubblicato in Senza categoria | Lascia un commento

Collegarsi a un host dietro NAT senza il port forwarding: ngrok (servizio gratuito di reverse tunnel)

Per permettere a un server l’esposizione delle proprie porte su internet, questo server necessita di un IP publico. Oppure di un IP privato, se il router sa dove instradare le connessioni in ingresso. Volendo realizzare un server che dispone di IP privato, non avendo la possibilità di configurare il port forwarding sul router, una delle soluzioni più pratiche è il reverse tunnel con ssh. Il problema è che bisogna disporre di un altro host con IP publico o portforwardato dove gira sshd (l’host in the middle) e questo non sempre è possibile. Fortunatamente ngrok si occupa di fare la macchina in the middle gratis. Basta scaricare il programma, disponibile anche per piattaforme arm (quindi per raspberry pi, banana pi, ecc), e iscriversi al sito.

Pubblicato in Senza categoria | Contrassegnato , , , | Lascia un commento

Gestione delle librerie in Linux

A volte capita di scrivere o trovare delle librerie scritte in C e a volte capita che non vengano installate automaticamente nelle directory giuste. Quindi in breve: i file header .h vanno in /usr/include, mentre le librerie vere e propre .a o .so vanno in /usr/lib. Non dimenticare di cambiare il propretario con chown root:root e i permessi di esecuzione chmod 755. Per dire al compilatore gcc di usare una libreria, bisogna aggiungere -lnomelibreriasenzalib dopo e solo dopo il nome del file .c da compilare e il file di output specificato con -o. Altro ancora qui.

Pubblicato in Senza categoria | Contrassegnato , , , | Lascia un commento