VoIP and Hacking | Consulenza Documentazione

Terminiamo qui la trattazione del software WISH citandone ancora alcune caratteristiche fondamentali, finora non menzionate.

Attività di log
Tutte le informazioni di log vengono registrate sul log di sistema dalla facility syslogd. La locazione attuale dei logs è definita in /etc/syslog.conf.  Tutti i messaggi vengono emessi in console per default.  Di seguito vi è una descrizione delle classi che il driver utilizza per il log di sistema.

kern.info: Tale tipo di informazione è costituita appunto da dati  informativi riportati dal driver. All’avviamento il driver registrerà la versione di ciascuno dei files nel modulo ed indicherà quello che è necessario avviare.

kern.warning: Tale tipo di informazione avvisa che qualche attività abbia fallito nell’essere completata ma che ciò non risulta fatale per il driver stesso.  Messaggi di warning si manifestano tipicamente allorquando il transceiver prematuramente smette di trasmettere dati in seguito ad una collisione sulla linea.  La maggior parte dei transceivers bidirezionali richiedono anche un protocollo di handshaking protocol per validare le comunicazioni e se tale protocollo incorre in un timeout durante l’attesa di un messaggio da parte del transceiver, verrà prodotto appunto un messaggio di warning.

kern.error: Tale tipo di informazione indica che si è verificato un errore catastrofico nel driver. Di conseguenza, il driver tentera di autoscaricarsi.  In molti casi il driver sarà incapace di farlo e risulterà pertanto inusabile o instabile.  È fortemente raccommandato un  reboot.

kern.debug: Tale tipo di informazione viene generata esclusivamente quando il parametro indicante debug viene passato al driver. È consigliabile che il driver non venga eseguito col debugging attivato a meno che non sia necessario effettuare una analisi. L’attivazione del debugging del driver produce una enorme quantità di dati e potrebbe quindi rapidamente gonfiare i log files di sistema.

In aggiunta ai logs di sistema, che vengono registrati sull’ hard disk, il driver mantiene un log in memoria.
Il log viene ripulito ogni volta che il device driver viene caricato oppure scaricato.
Il log contiene tutte le transazioni che si possono verificare in una rete X10 così come lo status virtuale di tutti i devices presenti sulla rete.  Lo status virtuale è una rappresentazione convenzionale ed assume che ciascun device sia una luce.

La distribuzione di WISH comprende anche utilities che potenziano l’utilizzo dei drivers. Sono elencate qui sotto e descritte quindi in dettaglio.

X10 Log Daemon: (deve essere eseguito come root o comunque come utente privelegiato da poter scrivere via syslog)

Gli argomenti per x10logd sono:

• -o: specifica il file name relativo al log output, (per default è /var/log/x10log se -s non viene specificato
• -i: specifica il device x10 che fa da log source, (per default corrisponde a /dev/x10/log)
• -d: attiva il debug
• -p: specifica il pid file, (per default è /var/run/x10logd.pid)
• -a: viene avviato all’inizio di un device log (per default il logging viene attivato solamente per quanto recevuto in seguit0 x10logd starts)
• -s: registra il log in output su syslog
• -t <tag>: Prepende un tag a ciascuna entry del log

Se venisse specificato il flag -s, e -o non venisse specificato, tutto il logging finirebbe su syslog e si identificherebbe come local5.*.
Se venisse specificato il flag -o e non quello -s, allora tutto il logging verrebbe indirizzato al file specificato dopo -o .
Se non fossero specificati nè -s nè -o, allora il logging andrebbe a finire per default su /var/log/x10log.
Se fossero entrambi specificati (sia -o che -s), allora il logging finirebbe sia su syslog che sul file specificato da -o.

Utility per la lettura non bloccante (nbread):

nbread è una utility che consente ad uno shell script di ottenere lo status di un device e restituire immediatamente i dati provenienti dal device sotto forma di una stringa. Tale utility si trova nella directory utils/ e viene installata come /usr/bin/nbread.  “nbread” accetta come argomento semplicemente il nome del file da leggere e continuerà a leggere fino a che non vi siano più dati disponibili. Essa restituisce tutti i dati allo script e quindi esce.  “nbread” costituisce un esempio di lettura non bloccante.

Gli argomenti per nbread sono:

* il device name da leggere

Utility Echo Non-Bloccante:

nbecho è una utility in grado di inviare testo ad un file (oppure lo standard output) col flag O_NONBLOCK impostato.  Tale utility si comporta in modo identico alla funzione “echo” ma non risulta bloccante. Il suo utilizzo dovrebbe permettere ad uno shell script l’invio di molti comandi alla rete X10 network senza attendere che i comandi accodati vengano effettivamente trasmessi alla rete.  Tale utility si trova nella directory utils/ e viene installata come /usr/bin/nbecho.  “nbecho” semplicemente effettua l’echoing di qualsiasi cosa venga passata come parametro allo standard output, potendo poi quest’ultimo essere rediretto su di un file.
Gli argomenti previsti da nbecho sono:

* il testo di cui effettuare l’ echo

Utility X10Watch:

x10watch è una utility destinata a controllare un singolo device x10 e compiere una azione quando il device cambia stato.
Questa utility deve essere eseguita come utente che abbia accesso in scrittura ai devices X10 ma non come root dal momento che le azioni che intraprende avvengono tramite una chiamata system().

La sintassi di x10watch è:  x10watch <device> [-0 <action off>] [-1 <action on>] [-t <tag>] [-p <seconds>]

Gli argomenti passabili ad x10watch sono:

• <device>:  Il device da controllare. Deve consistere in una singola unità la quale deve necessariamente venire specificata.
• -0 <action off>: Tale argomento è opzionale ed identifica il comando da eseguire quando il device passa dallo stato di on a quello di off. Occorre specificare almeno un argomento action.
• -1 <action on>: Tale argomento è opzionale ed identifica il comando da eseguire quando il device passa dallo stato di off a quello di on. Occorre specificare almeno un argomento action.
• -p <seconds>:  Numero di secondi di ritardo dopo ogni azione.

Gli argumenti action possono specificare una qualsiasi cosa invocabile a linea di comando e vengono passati alla shell per l’esecuzione. I seguenti sono comandi action validi:

1. # x10watch /dev/x10/a1 -0 “echo aoff > /dev/x10/e” -1 “echo aon > /dev/x10/e”
2. # x10watch /dev/x10/a1 -0 /usr/local/etc/x10_alloff.sh
3. # x10watch /dev/x10/a1 -1 /usr/local/etc/x10_allon.sh

Il primo controlla il device A1 e se questo passa da on a off, disattiverà tutte le luci per l’ housecode e. Se commutasse da off a on, attiverebbe tutte le luci per l’ housecode e.
Anche il secondo controlla il device A1, ed eseguirebbe /usr/local/etc/x10_alloff.sh, se A1 dovesse commutare da on a off. Non attuerebbe alcuna azione qualora A1 commutasse ad on
L’ ultimo esempio controlla il device A1, ed eseguirebbe /usr/local/etc/x10_allon.sh se A1 passasse da off a on. Non attuerebbe alcuna azione qualora A1 commutasse da on a off.

Perché utilizzare x10watch invece di nbread in uno shell script?
Esso offre il vantaggio di non essere mai costretto ad entrare in un ciclo di attesa. Semplicemente fa uso di una lettura bloccante per ottenere lo status di un device x10.  Se lo status non varia mai, il programma non intraprenderebbe mai alcuna azione, e ciò implica un system overhead molto modesto.