Pillole Unix/Linux: il comando grep

grep (GNU Regular Expression Parser) è un utilissimo programma per analizzare testi. A cosa serve analizzare un testo? per esempio: trovare tutti i documenti di testo dentro ad un disco o ad una directory in cui compare la parola “mail”, quando non abbiamo la più pallida idea di dove sia. Qui in realtà occorre un concorso di programmi: uno che fa la scansione dell’albero di filesystem e, in pipe, quello che analizza il file correntemente puntato dal primo programma.

Ad esempio mi pongo in una certa directory e lancio il programma

$ find . -name "*php" -exec grep -H "mail" {} \;

Il programma che scansiona l’albero da quel punto “.” in giù, alla ricerca di tutti i file che finiscono per php è find.

Il programma che analizza ogni singolo file ritornato da find è grep.

Ma concertiamoci su grep. Molti di voi lo sapranno già, ma io me ne sono reso conto stamattina. Il programma grep ha delle limitazioni abbastanza forti.

Ad esempio, questo comando dovrebbe ritornare 012, e invece non ritorna nulla:

$ echo 012 | grep "[0-9]+"
$

Eppure l’espressione regolare recita “una o più cifre”.

Magicamente ho scoperto che invece il comando egrep (extended grep) fa il suo lavoro:

$ echo 012 | grep "[0-9]+"
012

Cercando in rete questa cosa viene citata come una limitazione di grep. È tutto.

 

 

Pillole di TCP/IP: l’utility PING

Ping è un programma disponibile in tutti i sistemi operativi che permette di controllare se un host o più in generale, una qualsiasi interfaccia di rete anche di un router, è raggiungibile dal punto in cui siamo.

Ping è una utility che invia e riceve messaggi ICMP (Internet Control Message Protocol). Partiamo da questo protocollo.

ICMP è un protocollo (in sostanza, come tutti i protocolli, un set di comandi per svolgere una determinata operazione) di supporto della più vasta suite IP (Internet Protocol). Con ICMP non si trasferiscono messaggi creati dall’utente ma solo informazioni sullo stato della rete, di solito elaborate dagli stessi dispositivi che se li scambiano.

ICMP è stato definito dallo IANA nel settembre del 1981 per opera di Jon Postel (il papà anche di FTP e di DNS). La RFC in cui è definito è la rfc792.

I messaggi ICMP vengono inviati in diverse situazioni: per esempio, quando un datagramma (un pacchetto) non riesce a raggiungere la sua destinazione; quando un gateway (uno “smistatore”) non ha la capacità di accumulazione (buffering) necessaria per reindirizzare un pacchetto o quando il gateway può forzare l’host a inoltrare il traffico su un percorso (route) più corto. [1]

Facciamo anche un piccolo approfondimento sulla suite TCP/IP completa.

ICMP usa la suite IP come se fosse un protocollo di grado superiore, come TCP o UDP, ma è progettato come tutti i protocolli IP per essere non assolutamente affidabile (not absolutely reliable), in quanto non viene fatto un controllo sulla correttezza della trasmissione. Quindi ICMP è a tutti gli effetti parte del protocollo IP.

Infatti, il protocollo IP non è stato progettato per essere assolutamente affidabile. Lo scopo di questi messaggi di controllo è di fornire un feedback sui problemi di comunicazione, non quella di rendere il protocollo IP affidabile. Non c’è nemmeno la garanzia che un pacchetto di controllo sarà effettivamente inoltrato oppure che sarà  effettivamente ricevuto. Qualche pacchetto può venire perso (e con PING molte volte si può vedere che capita) senza alcuna informazione di ritorno sulla loro perdita. Nel quadro del protocollo TCP/IP, sono gli stessi protocolli di ordine superiore costruiti sopra IP che devono implementare le loro specifiche procedure di controllo se è richiesta una comunicazione affidabile.

Questo per una visione generale nel quadro del procollo TCP/IP.

I messaggi ICMP sono quindi dei datagrammi incapsulati dentro a pacchetti IP e sono usati sia con i protocolli IPv4 che con IPv6. Questi pacchetti partono con una intestazione IP, seguita dall’intestazione ICMP, il tipo, il codice, il codice di controllo (checksum) e i dati da trasmettere che sono determinati univocamente dai campi tipo e codice che identificano il messaggio da inviare. [2]

I tipi di messaggi ICMP che vengono  inviati esplorativamente per saggiare lo stato della rete, informano l’host sul verificarsi di varie circostanze:

  • rete non raggiungibile o di host non raggiungibile (Destination Unreacheable Message),
  • gateway sovraccarico (source quence message)
  • echo
  • Time Exceeded

 

I messaggi ICMP sono trasmessi con un messaggio IP ordinario la cui intestazione è

  • Versione (4 o 6)
  • IHL (Internet Header Length) di 32 bit
  • Tipo di servizio: 0
  • Identificazione, flag, fragment offset
  • TTL (Time To Live in secondi): essendo questo campo decrementato di uno da ogni macchina attraversata dal datagramma, il suo valore dovrebbe essere maggiore o uguale al numero di gateway che il datagramma attraversa.
    In altre parole, ogni router che prende in consegna un messaggio ICMP, decrementa questo valore di 1 e il pacchetto viene preso in gestione finché questo numero è positivo. Quando esso si annulla, il pacchetto viene scartato e non più inoltrato. Questo ha a che vedere con gli hop necessari a inviare un messaggio ICMP (un messaggio IP in generale) dalla sorgente alla destinazione. I nodi che può attraversare sono molti e uno degli scopi di ICMP è quello di trovare un routing ottimale che minimizzi il numero di hop necessari.
  • Protocollo: ICMP = 1
  • Header Checksum: codice di controllo dell’header, nella prima versione della RFC è i complemento a 1 dei primi 16 bit dell’header
  • Indirizzo IP sorgente
  • Indirizzo IP destinazione

La parte dati del datagramma poi inizia con il tipo del messaggio ICMP; i messaggi ICMP hanno tutti questa forma:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  <-- 32 bit
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             unused                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 64 bits of Original Data Datagram      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I tipi di messaggio (network/destination unreacheable, echo, time exceeded, …) sono determinati dal Type e dal Code.

Noi siamo partiti dal comando PING che in sostanza è l’invio un messaggio ICMP di tipo echo, ma i messaggi ICMP sono ordinariamente inviati dai vari dispositivi per informarsi sullo stato della rete.

Nel caso del ping, come detto, implementiamo un messaggio echo o reply che è così costituito:

  • Type: 0 (se messaggio echo) oppure 8 (se messaggio reply)
  • Code: 0
  • Checksum
  • Identificatore
  • Numero di sequenza, che è l’icmp_seq che leggiamo nel ping:
$ ping www.google.com
PING www.google.com (172.217.21.68) 56(84) bytes of data.
64 bytes from mrs08s05-in-f4.1e100.net (172.217.21.68): icmp_seq=1 ttl=49 time=78.1 ms
64 bytes from mrs08s05-in-f4.1e100.net (172.217.21.68): icmp_seq=2 ttl=49 time=64.4 ms
64 bytes from mrs08s05-in-f4.1e100.net (172.217.21.68): icmp_seq=3 ttl=49 time=60.9 ms
^C
--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 60.902/67.815/78.141/7.440 ms

Come funziona il datagramma ICMP di tipo echo/reply

I dati ricevuti dal messaggio di echo devono essere ritornati nel messaggio echo di risposta (reply).
L’identificatore e il numero di sequenza posso essere usati dal mittente il messaggio di echo per agevolare il confronto delle risposte con le richieste di echo.
Per esempio l’identificatore può essere usato come una porta TCP/UDP per identificare una sessione, e il numero di sequenza può essere incrementato da ogni invio di una richiesta echo. Il destinatario (echoer) ritornerà questi stessi valori nella risposta all’echo.

Quindi nell’output del messaggio ping vediamo il TTL, la sequenza del pacchetto e il round trip time (tempo di andata e ritorno tra un messaggio di echo e uno di reply).

Un’altra cosa importante nei messaggi ICMP è che non vengono creati messaggi ICMP per inoltrare messaggi ICMP (controllo lo stato della rete per mandare un messaggio di controllo di stato della rete) perché questo porterebbe presto al blocco dei dispositivi. A questo proposito, un ultimo aspetto importante da considerare è che spesso il comando ping non è determinante nel caratterizzare la raggiungibilità di un host. Infatti posso fare in modo che un certo host rigetti i comandi di echo per evitare di impegnare risorse a inoltrare un comando reply. Infatti ping spesso viene usato come attacco dDOS.

Quindi potremmo avere un web server perfettamente rispondente anche se non è reattivo al ping.

 

Bibliografia

[1] http://www.ietf.org/rfc/rfc792.txt

[2] https://www.pcwdld.com/what-is-icmp-and-port

Image: Piaxabay Creative Commons CC0

Pillole di Unix/Linux: i servizi, i runlevel e gli script rc.d

Un servizio è un programma, o un insieme di programmi, che gira in background e di cui non ci preoccupiamo fino al momento in cui ne abbiamo bisogno. Esempi di servizi sono Apache, MySQL e CUPS (il server per la gestione delle stampanti). Un servizio è detto a volte service e a volte server.

Un runlevel è una fase di funzionamento del sistema operativo inteso come insieme di servizi che vengono accesi quando si entra in una determinata fase dall’avvio.

Il sistema operativo parte sempre dal runlevel 1 (livello in cui è consentito un accesso ad un singolo utente), progressivamente attraverso i livelli 2, 3, 4 e 5, livello al quale possiamo cominciare a lavorare con tutti i servizi funzionanti, compresa la GUI (Graphics User Interface) cioè l’interfaccia grafica a cui siamo abituati da molto tempo. Il tutto si esaurisce nel tempo che intercorre tra l’accensione del computer e la comparsa della maschera di login, quindi generalmente – se la macchina ha subito una corretta manutenzione – alcuni secondi.

Esistono due ulteriori livelli:

  • il livello 0 nel quale il sistema operativo entra per eseguire un arresto (HALT)
  • il livello 6 nel quale il sistema operativo entra per eseguire un riavvio (REBOOT)

Varie versioni di Unix hanno storicamente sviluppato diverse versioni dei runlevels:

  • BSD (Berkeley Software Distribution) per esempio i runlevel non ha li ha proprio 🙂
  • System V (AT & T) ha i runlevel seguenti, ognuno dei quali prevede avvio di specifici servizi: ad esempio il 2 è un funzionamento multi utente senza la rete, il 3 è un funzionamento multiutente con la rete ma solo in modalità testo, …, il 5 funzionamento multi utente con rete e interfaccia grafica).
  • Debian (da cui deriva Ubuntu) hai il runlevel 1 single user text mode, e 3, 4 e 5 multi user completo.

L’ordine di avvio dei runlevel viene impartito al sistema operativo dal file /etc/inittab.

Per le versioni derivate da Debian (come Ubuntu) invece il file /etc/inittab non esiste e l’ordine viene invece scritto dentro ai file contenuti nelle directory rcX.d, dove X = 0, …, 6

Ci si può spostare di runlevel all’occorrenza, ad esempio se si verificano errori strani o ci sono servizi che non partono. Basta scrivere da terminale (occorrono i privilegi di root)

# init [runlevel]

Se runlevel è eguale a 0 o 6, rispettivamente arrestiamo o riavviamo  la macchina.

Scrivendo il comando init 4, ad esempio, il sistema carica ed esegue gli script contenuti nella directory /etc/rc4.d/

Attenzione: ci sono situazioni nelle quali non è possibile aprire una shell e digitare il comando init . Questo accade ad esempio se proprio X (il server grafico) si è inchiodato (non risponde il mouse, non rispondono le finestre). Niente paura, questo non è Windows: possiamo entrare in una shell a runlevel 4 (solo testo) con la combinazione di tasti Ctrl+Alt+F6 o F7… ognuna delle quali combinazioni aprirà una shell di testo a schermo intero (in runlevel 4, il sistema è in modalità multi utente) dal quale si potrà agire sul servizio che non risponde (in questo caso ad esempio si può operare un riavvio di X). Ad esempio potremmo identificare l’id del processo X e killarlo. A quel punto X ripartirà automaticamente.

init è il padre di tutti i processi, il programma che lancia il sistema operativo. È senza dubbio il programma più importante del sistema operativo. Possiamo vedere ciò in quanto il suo PID (Process ID) è sempre il numero 1:

$ ps aux 
USER PID %CPU %MEM    VSZ  RSS TTY STAT  START TIME COMMAND
root 1    0.0  0.0 185152 5816   ?   Ss  11:29 0:01 /sbin/init splash
root 2    0.0  0.0      0    0   ?    S  11:29 0:00 [kthreadd]
root 3    0.0  0.0      0    0   ?    S  11:29 0:00 [ksoftirqd/0]
root 5    0.0  0.0      0    0   ?    S< 11:29 0:00 [kworker/0:0H]
root 7    0.1  0.0      0    0   ?    S  11:29 0:13 [rcu_sched]
root 8    0.0  0.0      0    0   ?    S  11:29 0:00 [rcu_bh]
...

 

Bibliografia

[1] http://www.linux.com

[2] Stephen Coffin, UNIX System V Release 4, 1990 McGraw-Hill

La codifica base64

Questa codifica permette di rappresentare file binari (o anche file di testo) in un formato che usa una base di soli 64 caratteri scelti tra i 128 caratteri dell’ASCII standard 7 bit: quale insieme? dipende dalla particolare implementazione, ma fondamentalmente sono

  • i 26 caratteri Maisuscoli [A-Z], seguiti
  • dai 26 caratteri minuscoli [a-z], seguiti
  • dalle 10 cifre [0-9] e
  • dai segni + [più] e / [slash]

È una tabella composta quindi di 26+26+10+2 = 64 caratteri.

A cosa è dovuto questo che potrebbe sembrare un arzigogolo inutile?

La posta elettronica si basa su questa codifica, per esempio: gli allegati alla mail, quale che sia il loro tipo MIME (sia esso un pdf, un breve video o un audio), vengono convertiti in TESTO puro.

Perché la trasmissione di mail è su base TESTUALE, si trasmette testo. Così anche HTTP: Hyper TEXT Transfer Protocol. Le immagini e i file multimediali in genere che viaggiano su HTTP vengono precedentemente convertite in TESTO.

Lo schema di codifica è il seguente: supponiamo di dover trasmettere con un protocollo di testo (SMTP o HTTP) la stringa “CIAO”.

Prendiamo per ciascun carattere la corrispondente codifica ASCII in binario e ne raggruppiamo le cifre 6 a 6:


Algoritmo per la determinazione dei caratteri base64

Quindi 0 viene mappato in A, 1 in B e così via, fino 61 che viene mappato sul carattere 9, più 62 mappato in + e 63 in /

L’algoritmo prevede che il numero di bit debba essere multiplo di 6, per cui eventualmente si opera un padding (i 4 zeri verdi nel nostro caso); inoltre il numero di caratteri dev’essere multiplo di 4 per cui u questo caso si aggiungono da 0 a due caratteri =.

Varie implementazioni ritornano valori finali leggermente diversi: ad esempio, per evitare problemi inserendo una stringa base64 nell’URL, è necessario evitare il carattere /.

Nella mia implementazione Ubuntu:

$ base64 --version
base64 (GNU coreutils) 8.23
Copyright © 2014 Free Software Foundation, Inc.
Licenza GPLv3+: GNU GPL versione 3 o successive <http://gnu.org/licenses/gpl.html>
Questo è software libero: è possibile modificarlo e ridistribuirlo.
Non c'è ALCUNA GARANZIA, nei limiti permessi dalla legge.

Scritto da Simon Josefsson.

il risultato è

$ echo CIAO | base64
Q0lBTwo=

il padding, in questa implementazione, viene fatto con o=.

Per una immagine il procedimento è lo stesso: si prendono i bytes, si raggruppano per 6, si converte nei caratteri della tabella A-Za-z0-9+/ più eventuale padding

  • di zeri per arrivare ad un numero di bit multiplo di 6 e
  • di caratteri per arrivare ad un numero di caratteri multiplo di 4.

Pillole UNIX: acquisire il DNS dal server attraverso una sessione VPN

Mi sono imbattuto in questo problema.

Per accedere alla rete aziendale di un cliente in modo sicuro mi è stato assegnato un collegamento VPN che ho utilizzato mediante un client OpenVPN.

Lo script di configurazione del client però mancava delle istruzioni per acquisire gli IP del DNS necessari per navigare una volta collegati.

Ciò che succedeva era che la connessione era stabilita ma mi dovevo salvare in /etc/hosts gli indirizzi e i nomi delle macchine che volevo raggiungere, lavoro che di solito è svolto dal DNS aziendale.

Su imbeccata di un collega ho trovato la soluzione in questa risorsa che consiste nell’aggiungere in coda al file di configurazione del client queste istruzioni:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Il file resolv.conf non è editabile a mano perché viene sovrascritto dal sistema operativo (dal programma resolvconf nello specifico) ogni volta che si cambia la configurazione della rete. Nel file update-resolv-conf vengono analizzate le opzioni DHCP provenienti dal server openvpn al fine di aggiornare correttamente il file resolv.conf. In effetti adesso il file resolv.conf contiene i riferimenti necessari a navigare all’interno della rete aziendale:

$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.170.5.1
nameserver 10.170.5.2
nameserver 127.0.1.1
search company.domain.com

Prima della modifica invece avevo

$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1

e quindi vedevo solo il mio pc.

Centrare verticalmente blocchi div con CSS2

Per centrare verticalmente un blocco testo, se questo è composto di una sola linea, è necessario specificare oltre all’altezza del contenitore div anche l’altezza della linea di testo e queste devono coincidere:

HTML

<div>blocco centrato verticalmente</div>

 

CSS

div
{
  height: 200px;
  line-height: 200px; /* <-- devi aggiungere questa */
  vertical-align: middle;
}

Per un testo multi riga, è sufficiente racchiuderlo in un ulteriore blocco span.

CSS

div
{
  height: 200px;
  line-height: 200px;
}

span
{
  display: inline-block;
  vertical-align: middle;
  line-height: 14px; /* <-- regolare questo */
}

[Fonte: StackOverflow]

 

 

Reverse DSN: recuperare un nome host da un indirizzo IP

Normalmente una query, una interrogazione, DNS parte da un nome host e risulta in un indirizzo IP

nslookup è una utility che appoggiandosi, ad un server di nomi, restituisce la risposta:

$ nslookup www.google.com
Server: 127.0.1.1
Address: 127.0.1.1#53

Non-authoritative answer:
Name: www.google.com
Address: 216.58.205.36
Normalmente nslookup fa la query ad un server di default, che in questo caso è il 127.0.1.1, il quale da una risposta non autoritativa o non autorevole, non essendo il server che possiede questo record (www.google.com); quindi si tratta di una coppia {host;ip_address} che ha nella cache locale.
Possiamo anche chiedere ad un diverso nameserver specificando l’indirizzo IP (es. x.y.z.w) come secondo argomento del comando:
$ nslookup www.google.com x.y.x.w
Qualora nslookup non trovasse questo nome nella cache locale, chiede al DNS di riferimento della rete a cui il computer è connesso, il quale a sua volta può contenere nella sua cache il record e rispondere non autorevolmente oppure, in caso contrario, fare riferimento al DNS del provider, e via così finché si arriva al possessore del record. Il meccanismo di cache serve proprio ad evitare questa catena di interrogazioni ogni volta che si chiama un certo host.

Diverso è il discorso se stiamo cercando l’host name di una macchina di cui siamo a conoscenza dell’indirizzo IP. Questo tipo di interrogazione è una interrogazione inversa e viene chiamata rDNS (r per reverse).

Il DNS inverso è controllato da chiunque sia il possessore dell’indirizzo IP. Egli può scegliere di delegare DNS inversi per un certo sottoinsieme di suoi indirizzi, cioè può scegliere di far fare questo lavoro ad un altro name server; il quale a sua volta può delegare un altro name server a gestire un sottoinsieme degli indirizzi IP che ha in gestione, e così via.

Alla fine, IANA “possiede” tutti gli indirizzi IP di internet. IANA delega questi indirizzi IP a 5 registri regionali:

E questi registri delegano i loro indirizzi IP ai fornitori di accesso a dorsale e, via via, agli ISP (Internet service Providers) fino agli utenti finali.

Dunque, su Internet, se volete controllare le query inverse sul DNS per il vostro indirizzo IP, dovete contattare il gestore che vi fornisce questo indirizzo IP e chiedergli di farvi una delega da installare nei vostri server DNS.

Per esempio se il vostro range di IP va da 1.2.3.0 a 1.2.3.255 allora la delegazione DNS inversa tipicamente si ottiene aggiungendo al vostro DNS la zona DNS “3.2.1.in-addr.arpa”.

Se dovete gestire uno o pochi indirizzi IP la procedura è leggeremente diversa. Si faccia riferimento alla RFC2317 per dettagli.

[Tutta la storia su Simpledns.com]

 

UNIX Pillole: scansionare una directory alla ricerca di una stringa in un file

Per cercare una stringa in un file possiamo utilizzare il comando grep:

$ cat multibox.html | grep result
Il file binario (standard input) corrisponde

come si vede però se il file è considerato come binario non ottengo informazioni utili.

 

Il seguente comando invece cerca le stringhe anche all’interno di un file binario:

$ strings -f *.html | grep result

file1.html: <div id="result" class="result">
file1.html: <table id="resulttable">
file2.html: <div id="result" class="result">

 

MySQL – gestione degli errori in inserimenti con valori nulli

mysqlSe cerchiamo di inserire dei valori nulli in un campo di una tabella dichiarato NOT NULL, il comportamento del DBMS MySQL è diverso a seconda della query che lanciamo, sulla base di un parametro di configurazione del server.

 

 

 

 

Ad esempio questa query cerca di inserire un valore null in una campo dichiarato not null (user_id):

insert into playlist(name, user_id) values ('ooo', null)

risultando in un errore:

Error Code: 1048. Column 'user_id' cannot be null

Ma se il campo non lo citiamo proprio:

insert into playlist(name) values ('ooo')

viene generato solamente un warning:

1 row(s) affected, 1 warning(s): 1364 Field 'user_id' doesn't have a default value

ed il record viene inserito lo stesso e viene forzato il valore del campo a 0 (se il campo è di tipo numerico) o a stringa vuota (se il campo è di testo).

Per evitare questo comportamento ed avere un comportamento coerente (errore in ogni caso) si deve modificare la proprietà sql_mode del DBMS :

set sql_mode = 'TRADITIONAL';

nel mio DBMS era impostata di fabbrica a

> select @@sql_mode

> NO_ENGINE_SUBSTITUTION

che è la proprietà che consente di NON sostituire automaticamente con InnoDB il motore di default in caso di non dichiarazione nelle istruzioni DDL come create table o alter table.

Per maggiori informazioni sui valori della variabile sql_mode e sulle combinazioni di valori, consultare il sito MySQL.

 

 

Francesco Vedovato illustra all’IQC di Waterloo lo stato della Comunicazione Quantistica in spazio libero

Quantum Communication e Quantum Computing sono le frontiere più promettente del prossimo futuro in chiave di comunicazioni, sicurezza e velocità di elaborazione.

Francesco Vedovato, un dottorando di ricerca che lavora nel gruppo Quantum Future del DEI di Padova, diretto dal prof. Paolo Villoresi, sta studiando proprio questo tipo di comunicazioni.

Nel video che segue Francesco illustra all’Institute of Quantum Computing dell’Universtià di Waterloo (Ontario, Canada) i risultati del lavoro nell’ambito del progetto di Comunicazione tra Terra e satelliti LEO (Low Earth Orbit), svolto dal gruppo Quantum Future in collaborazione con il Matera Laser Ranging Observatory.

Il talk risale ad agosto 2016.