La Khan Academy  è una organizzazione no-profit che ha come obiettivo quello di fornire un’e-learning di alta qualità, ma gratuito ed accessibile a tutti. Sul sito è possibile trovare i link ad oltre 1600 video ospitati su Youtube, i quali coprono già diverse discipline, sopratutto scientifiche. Si va dalla chimica alla biologia, dalla fisica alla matematica, cui viene dedicata un’attenzione particolare, a tutti i livelli, a partire dall’aritmetica di base, fino ad arrivare all’analisi matematica più avanzata.

I video sono tutti di durata approssimativamente variabile tra i 10 edi 20 minuti e sono stati realizzati tutti dallo stesso Salman Khan, fondatore della Academy, nei pomeriggi liberi che la sua attività nel management finanziario gli consentiva. Attualmente Sal, che ha un solidissimo background in matematica ed in computer science, ha lasciato il proprio lavoro per dedicarsi interamente a questo progetto, grazie al contributo finanziario di alcuni benefattori.

La dedizione e la motivazione con cui Sal intende questo compito hanno sicuramente qualcosa di spirituale, che forse deriva dalla propria origine indiana (è nato a New Orleans da madre di Calcutta e padre del Bangladesh).
Egli ha inoltre sviluppato un metodo per analizzare l’efficacia dei video che realizza: di conseguenza è riuscito a stabilire delle metriche che lo aiutano a decidere la durata ottimale di una lezione o quali siano i punti di un video che risultano più difficili da comprendere.

Le intenzioni dichiarate sono quella di estendere la gamma delle discipline trattate “to cover everything” (per usare le parole dello stesso Khan), e di raggiungere la indipendenza economica entro 5 anni, appaggiandosi a qualche fondazione, per non perdere la caratterizzazione open-source del progetto.
Le premesse sono ottime, considerato il successo (oltre 200000 studenti seguono mensilmente le varie lezioni), e il fatto che lo stesso Bill Gates (che forse non ha colto la filosofia open-source dell’iniziativa, o forse semplicemente se ne frega quando non si tratta del codice Microsoft) si è dichiarato entusiasta della iniziativa.

Send post as PDF to

Che si chiami la propria banca, una qualsiasi azienda, un ufficio o servizio pubblico, diviene sempre più probabile inbattersi in una serie di opzioni IVR cui rispondere premendo tasti corrispondenti a cifre, asterisco e cancelletto, in varie salse e combinazioni.

Pertanto, quando si configura professionalmente un server asterisk, assume grande importanza un altrettanto corretto setup del suo meccanismo di rilevamento dei DTMF.

Per poter configurare correttamente la gestione dei DTMF, è forse utile sapere che esistono due tipi di DTMF: inband ed out-of-band.

Inband sono quei toni DTMF che sono a tutti gli effetti segnali audio. Quando si preme un tasto numerico (ad esempio) del dialpad di un terminale telefonico, il tono che si ode dovrebbe essere esattamente quello che viene udito dal sistema telefonico all’altro capo, per poter essere affidabile. Il tipico problema della tecnologia DTMF inband è che il sistema telefonico può confondere suoni di un alto come DTMF random. Succede realmente che una donna, mentre parla al telefono, rilevi in sottofondo un DTMF senza aver realmente premuto alcun tasto.

Una voce femminile, essendo caratterizzata da toni piu alti può venire più facilmente riconosciuta, incorrettamente, come un DTMF rispetto ad una voce maschile.

Un altro inconveniente dei DTMF inband consiste nel fatto che se la linea è cattiva e se per questo una chiamata vocale non risultasse chiara, i DTMF non verrebbero inviati correttamente e il terminale all’altra estremità non sarebbe pertanto in grado di interpretarli correttamente.

Un fastidioso rumore di fondo pure può causare lo stesso effetto.
L’utilizzo di un qualsiasi codec diverso da g711/ulaw/alaw risulterà generalmente in una distorsione dell’audio dei DTMF.
I DTMF inband non sono infatti supportati sul codec g729.

I DTMF out-of-band invece non soffrono di questi problemi. Non si tratta infatti di un segnale audio, ma di un segnale digitale che non viene influenzato dai fattori appena visti. Tuttavia richiedono che la parte inviante, tipicamente il telefono, possieda anch’esso la capacità di inviare DTMFs out-of-band. Sfortunatamente i normali telefoni casalinghi, ma questo vale anche per i cellulari, non possono trasmettere DTMF out-of-band.

Out-of-band è una modalità affidabile per l’invio di DTMF che a sua volta comprende due modalità distinte: SIP-INFO ed RFC2833.
SIP-INFO non viene molto utilizzato mentre RFC2833 [Schulzrinne e Petrack (2000)], che descrive come trasportare la segnalazione DTMF, altri toni di segnale, ed eventi telefonici, all’interno di pacchetti RTP (Reat Time Protocol), è diventato lo standard di fatto relativamente all’uso dei DTMF out-of-band nel VoIP, quando si utilizza SIP.

Quando si imposta un sistema Asterisk destinato a  interfacciarsi solamente con altri sistemi puramente VoIP, non vi è motivo di preoccuparsi, così come purtroppo non vi è molto da fare relativamente a chiamate provenienti da sorgenti non VoIP.

Tutti gli IP phones possiedono la capacità di usare DTMF sia inband che out-of-band. Per default la maggior parte di essi è gia impostata ad usare la modalità RFC2833.
Non occorre modificarla, ma solo verificare che per caso non sia impostata in modo differente.

Dal lato Asterisk, non importa quale versione si usi, i toni DTMF verranno tranquillamente accettati senza alcuna configurazione extra.

Se ad un sistema Asterisk si interfacciano sia terminali VoIP che terminali o linee analogiche, potrebbe essere necessario apportare delle modifiche al file zapata.conf (o chan_dahdi.conf). Questo perché zapata.conf (o chan_dahdi.conf) è il file che si occupa della configurazione dell’ hardware che abilità i telefoni e le linee non VoIP a connettersi al server Asterisk.
Se asterisk riceve correttamente i DTMF dagli IP phones ciò non implica che li debba ricevere altrettanto bene da parte di apparecchi o linee analogiche. Le modifiche a zapata.conf (o chan_dahdi.conf) si limitano poi al tuning dei valori rxgain, txgain e relaxdtmf.
Pertanto il valore di default rxgain=0.0 può venire modificato mentre relaxdtmf=no può venire cambiata in relaxdtmf=yes. Ma ancora una volta, se i toni DTMF dovessero giungere poco chiari a causa di una connessione di cattiva qualità, Asterisk faticherebbe certamente ad interpretarli, e potrebbe non riconoscerli del tutto.

Se una chiamata provenisse pertanto da una sorgente analogica, ad esempio un normale fisso, oppure da un cellulare, significherebbe che eventuali DTMFs entranti sarebbero solamente di tipo inband e non ci sarebbe un gran chè su cui intervenire.
Se la chiamata proviene da un cellulare, che trasmette i DTMF come segnali audio, un server Asterisk potrebbe non essere in grado di intercettarli distintamente. Non si potrà mai conoscere i percorsi che tali DTMF hanno compiuto e quanto ciò possa aver apportato loro una qualche distorsione prima di raggiungere il server asterisk.

Alcuni utenti hanno riportato che la rimozione di ogni riferimento ad un qualsiasi DTMF mode sui propri PBX Asterisk ha risolto qualsiasi inconveniente precedentemente incontrato con i DTMF. Ciò si effettua editando sip.conf per rimuovere qualsiasi riferimento a linee tipo “dtmfmode=rfc2833″ o “dtmf=inband”, consentendo di fatto ad Asterisk negoziare la modalità DTMF in modo autonomo.

Tuttavia, alcuni devices (Linksys, alcuni IP phones) richiedono l’impostazione di un DTMF mode. In tal caso, si consiglia di scegliere RFC2833 come DTMF mode. Se non dovesse funzionare occorre tentare le altre opzioni possibili, inband o SIP INFO.

L’importanza di aggiornare la versione di Asterisk
Versioni datate di Asterisk (tipicamente pre-1.4) evidenziano problemi coi DTMF più di quanto avvenga con versioni più recenti. Fix relativi al miglioramento del mode rfc2833 sono presenti nella versione 1.6 (1.6.2.11) mentre nella 1.8, che attualmente si trova in beta version (è stata appena annunciata la release di Asterisk 1.8.0-beta3), ha fatto la sua comparsa un enhancement relativo ai DTMF inband.

Send post as PDF to

La sintassi standard è falsamente user friendly, rendendo difficoltoso redigere dialplans complessi, ed, molto spesso, ancora più difficoltoso interpretarli.
AEL invece rende la scrittura di un dialplan una attività più semplice e rapida, specialmente nel caso in cui sistemista Asterisk provenga dal mondo IT, dato che la sua sintassi lo rende simile ad uno dei tanti linguaggi di programmazione con cui avrà probabilmente avuto familiarità.
AEL è infatti concepito per fornire un linguaggio di programmazione per la scrittura di un dialplan per Asterisk.

Il parser AEL (pbx_ael.so) è totalmente separato dal modulo che effettua il parsing di extensions.conf (pbx_config.so).
Per usare AEL, è necessario solamente che il modulo pbx_ael.so venga caricato da Asterisk. Ciò avviene automaticamente impostando ‘autoload=yes’ in /etc/asterisk/modules.conf.
Una volta che il modulo è caricato, ricerca il file “extensions.ael” in /etc/asterisk/.

Extensions.conf ed extensions.ael possono operare in sinergia.
Alcuni utenti preferiscono ad esempio mantenere extensions.conf per le features configurate nella sezione ‘general’.

Ecco alcune indicazioni che spero possano riuscire ad invogliare qualcuno ad iniziare a scrivere in AEL.

Contesti
Un contesto (context) in AEL rappresenta un set di extensions esattamente nella stessa maniera in cui lo fa in extensions.conf.

context default {

};

NOTA: La parentesi graffa aperta deve essere usata come nello schema precedente. Spostarla sulla linea seguente può avere conseguenze imprevedibili!

Se il file extensions.ael non esistesse nella directory /etc/asterisk, basta crearlo assegnandone la opportuna proprietà all’utente con cui viene eseguito Asterisk. Può essere reso normalmente leggibile per tutti gli altri utenti.

# touch /etc/asterisk/extensions.ael
# chown asterisk:asterisk /etc/asterisk/extensions.ael

Per iniziare, se considerassimo, in extensions.conf, un context tipo il seguente:

[context-stupido]
exten => 333,1,Wait(3)
exten => 333,n,Answer()
exten => 333,n,Playback(benvenuto)
exten => 333,n,MusicOnHold()
exten => h,1,NoCDR()
exten => h,n,Hangup()

Potremmo facilmente dedurne che la ripetizione di “exten => 333,…” è un po’ noiosa e sarebbe auspicabile non fosse necessaria. E che la sua presenza aggiunge inoltre una certa complessità visiva al codice, anche se si tratta di codice molto semplice.

La stessa cosa in AEL potrebbe venire espressa così:

context context-stupido => {
   111 => {
      Wait(3)
      Answer();
      Playback(benvenuto)
      MusicOnHold();
   };
   h => {
      NoCDR();
      Hangup();
   };
};

Il codice AEL si presenta meglio e risulta più chiaro e leggibile rispetto alla versione standard. Forse non così tanto come in questo esempio così banale, ma se il dialplan dovesse ingrossarsi, ciò diventerebbe immediatamente evidente.

In AEL un context viene definito come un blocco di codice, esattamente come in buona parte dei più comuni linguaggi di programmazione, compreso cioè fra parentesi graffe, costituito a sua volta da un insieme di blocchi relativi ad extensions. E sempre come nei più comuni linguaggi di programmazione, ciascuna linea (statement) termina con un segno di “punto e virgola” (semi-colon).

Nel context di esempio la extension 333, dopo aver atteso 3 secondi prima che la controparte ottenga risposta, emette un messaggio di benvenuto e successivamente attiva la applicazione MusicOnHold, mentre la extension h termina la chiamata assicurandosi che i relativi dettagli non vengano registrati (NoCDR).

Includes
I contexts possono venire inclusi in altri contesti. Tutti i contexts inclusi sono elencati in un singolo blocco.

context default {
    includes {
         locali;
         extraurbane;
         internazionali;
    };
};

Dopo aver modificato il file extensions.ael, occorre impartire, nella CLI di Asterisk il comando “ael reload” per rendere operative le modifiche (conformemente ad uno stile comune a tanti altri moduli).

Variabili
Le variabili in Asterisk non sono tipizzate, pertanto, per definire una variabile, basta specificarla assegnandole un valore.

Le variabili globali vengono impostate nel loro specifico blocco.

globals {
    CONSOLE=Console/dsp;
    TRUNK=Zap/g2;
};

Le variabili (locali) possono essere impostate nelle extensions.

context foo {
    555 => {
         x=5;
         y=quiquoqua;
         quoziente=10/2
         NoOp(x vale ${x} ed y vale ${y} mentre quoziente vale ${quoziente} !);
    };
};

MACRO
Come la scrittura dei contexts, la scrittura delle MACRO è altrettanto semplice.
Le MACRO sono un po’ come le functioni o i metodi e vengono definite tramite la keyword “macro”, seguita da eventuali argomenti racchiusi tra parentesi tonde.

macro musica-di-attesa () {
   MusicOnHold();
};

equivale alla MACRO nel tipico stile di extensions.conf:

[macro-musica-di-attesa]
exten => s,1,MusicOnHold()

Gli argumenti passati alla MACRO vengono quindi riferiti dallo stesso nome.

macro std-exten( ext , dev ) {
       Dial(${dev}/${ext},20);
       switch(${DIALSTATUS) {
       case BUSY:
               Voicemail(b${ext});
               break;
       default:
               Voicemail(u${ext});

       };
};

Una MACRO viene invocata in AEL tramite un simbolo di “ampersand” (&) seguito dal nome della MACRO e gli argomenti tra parentesi tonde, o parentesi tonde vuote in assenza di argomenti.
Ad esempio, se combinassimo il context con la MACRO visti entrambi in precedenza, la cosa apparirebbe così:

context context-stupido => {
   111 => {
      Wait(3)
      Answer();
      Playback(benvenuto)
      &musica-di-attesa();
  };
  h => {
    NoCDR();
    Hangup();
  };
};
macro musica-di-attesa () {
   MusicOnHold();
};

Lo statement catch nelle MACRO
È spesso motivo di confusione tra i neo utenti di AEL il modo di usare extensions speciali come h, t o i in una MACRO.
Lo si fa utilizzando lo statement catch come nell’esempio seguente (un blocco catch può venire specificato per catturare le estensions speciali.

macro std-exten( ext , dev ) {
       Dial(${dev}/${ext},20);
       switch(${DIALSTATUS) {
       case BUSY:
               Voicemail(b${ext});
               break;
       default:
               Voicemail(u${ext});

       };
       catch a {
               VoiceMailMain(${ext});
               return;
       };
};

Ricordiamo che in questo caso la extension a (abort) verrebbe raggiunta premendo * (asterisco).

macro musica-di-attesa () {
   MusicOnHold();
   catch h {
      NoCDR();
      Hangup();
   };
};

Labels e GoTo
Anche l’uso delle labels in AEL è più intuitivo.
Una label la si specifica facendola seguire da un simbolo di due punti (colon), equindi usando lo statement goto per saltare ad essa. Ciò risulta valido sia per i contexts che per le MACRO.

Si consideri il seguente esempio in sintassi standard:

[esempio-label]
exten => 111,1,Set(COUNT=0)
exten => 111,n(incremento),Set(COUNT=$[${COUNT}+1])
exten => 111,n,GotoIf($["${COUNT}">"5"]?4:5)
exten => 111,n,Goto(termine)
exten => 111,n,SayDigits(${COUNT})
exten => 111,n,Goto(incremento)
exten => 111,n(termine),Hangup()
exten => h,1,NoCDR()
exten => h,n,Hangup()

Si tratta evidentemente di un contatore, che incrementa una variabile fino a 5 e quindi salta alla extension h terminando la chiamata. Ha due labels: incremento e termine.
Appare un po’ confuso, e in particolare la ripetizione di “exten => 111,n” la si sospetta inutile.

Lo stesso codice in AEL potrebbe essere espresso come segue:

context esempio-label {

111 => {
   Set(COUNT=0);
   incremento:
      Set(COUNT=$[${COUNT}+1]);
      if("${COUNT}">"5") {
      goto termine;
   };
   SayDigits(${COUNT});
   goto incremento;
   termine:
      Hangup();
   };

   h => {
      NoCDR();
      Hangup();
   };
};

Certamente ora appare meglio organizzato, facile da leggere e da comprendere. In altri termini, più professionale.

Lo statement “goto label” segue lo stesso comportamento della applicazione Goto(), ad eccezione del fatto che l’ultimo valore deve consistere in una label. De la label non esistesse, si otterrebbe un errore di run-time. Se invece la label esiste, ma in una differente extension, occorre specificare il nome della extension name oltre alla label nel goto; se la label si trovasse in un context differente, occorrerebbe specificare context|extension|label.

context esempio-goto {
    s => {
        inizio:
        NoOp(Loop Infinito!);
        Wait(1);
        goto inizio;    // va alla label nella stessa extension
    };
    3 => {
            goto s|inizio;   // va alla label in una extension differente
    };
    4 => {
            goto esempio-goto|s|inizio;  // va alla label in una extension differente dello stesso context
    };
};

context esempio-goto2 {
     s =>  {
         fine:
         goto esempio-goto|s|inizio;   // va alla label in un context differente
     };
};

Strutture condizionali
In precedenza si è fatto uso dello statement if, ancora qualcosa che viene usato in tutti i linguaggi di programmazione.
Si tenga conto che avendo una causola “else”, occorre necessariamente mettere delle parentesi graffe a delimitare la porzione non-else dello statement if.
Analogamente allo statement “if”, AEL supporta lo statements “switch”.

context conditional {
    _8XXX => {
         Dial(SIP/${EXTEN});
         if ("${DIALSTATUS}" = "BUSY") {
              Voicemail(${EXTEN}|b);
         } else {
              Voicemail(${EXTEN}|u);
         }
    };
    _777X => {
         switch (${EXTEN}) {
              pattern N11:
                   NoOp(You called a N11 number-- ${EXTEN});
                   break;
              case 7771:
                   NoOp(You called 7771!);
                   break;
              case 7772:
                   NoOp(You called 7772!);
                   break;
              case 7773:
                   NoOp(You called 7773!);
                   // fall thru-
              default:
                   NoOp(In the default clause!);
         };
    };
};

Loops
AEL possiede una propria implementazione di strutture iterative, come i loops “for” e “while” .

context cicli {
    1 => {
         for (x=0; ${x} < 3; x=${x} + 1) {
              Verbose(x vale ${x} !);
         }
    }
    2 => {
         y=10;
         while (${y} >= 0) {
              Verbose(y vale ${y} !);
              y=${y}-1;
         }
    }
}

AEL v.2
AEL v.2, che è la versione più recente di AEL, ha esteso il linguaggio all’uso di una sintassi più flessibile (lo strano vincolo del posizionamento della parentesi graffa aperta sembrerebbe non avere più senso), fornendo inoltre messaggi di errore più comprensibili, ed alcune funzionalità fin qui mancanti.

AEL2 offre differenti modi per esprimere la stessa cosa. E così, una serie di scelte può venire annidata così:

ifTime(*|*|20-25|dec)
{
       Playback(auguri/natale);
}
else
{
       ifTime(*|*|31|dec)
       {
                Playback(auguri/fineanno);
       }
       else
       {
               ifTime(*|*|1|jan)
               {
                       Playback(auguri/nuovoanno);
               }
               else
               {
                       ifTime(*|*|14|feb)
                       {
                               Playback(auguri/sanvalentino);
                               else {Playback(benvenuti); };
                       }
               }
        }
}

Oppure espressa in forma equivalente così:

ifTime(*|*|20-25|dec) {
               Playback(auguri/natale);
}
else ifTime(*|*|31|dec) {
               Playback(auguri/fineanno);
}
else ifTime(*|*|1|jan) {
               Playback(auguri/nuovoanno);
}
else ifTime(*|*|14|feb) {
               Playback(auguri/sanvalentino);
}
else {
               Playback(benvenuti);
}

Jump
Per richiamare una diversa extension (oppure, in uno statement switch, un altro “case”), si usa lo statement “jump”:

context incoming {
   s => {
        NoOp(Qui viene gestita la chiamata);
   };
   0437945876 => jump s; // vengono accettate le chiamate PSTN destinate a tale numero
};

context home-test {
   999 => jump s@incoming; // 999 serve a simulare una chiamata in ingresso
};

Considerazioni finali
Per concludere questa breve incursione nel mondo di AEL, occorre ammettere che è piuttosto strano che esso non sia stato accolto ed adottato dalla comunità Asterisk come meriterebbe, e che la maggior parte dei membri della stessa continuino a combattere con la sintassi standard per scrivere dialplans anche complessi, compito che diventa progressivamente più arduo se il dialplan cresce.
Apprendere AEL è molto semplice e coloro che conoscessero, oltre alla sintassi standard, anche un qualsiasi linguaggio di programmazione, potrebbero passare tranquillamente ad AEL in una manciata di ore, acquisendo in cambio notevoli vantaggi.

Come ultima indicazione, non bisognerebbe inserire nuovo codice in /etc/extensions.ael senza prima averlo testato con il tool aelparse.

Il tool aelparse viene compilato a partire dal relativo codice presente nella directory utils/ dei sorgenti di Asterisk.
Si tratta di un eseguibile stand-alone che prevede le opzioni -d, -w, -q, e -n.

• -d: Usando tale opzione, anziché leggere il file extensions.ael2 o extensions.ael da /etc/asterisk (o dalla directory deputata a contenere i files di configurazione) aelparse esamina la directory corrente. Ciò risulta molto utile per poter testare il dialplan senza compromettere l’ambiente di produzione.

• -w: Convert il file dialplan di input (extensions.ael2) nel formato extensions.conf, ed archivia tale file nella directory corrente col nome di “extensions.conf.aeldump”.
  A cosa dovrebbe mai servire? Be, potreste prendere tale file ed utilizzarlo su una versione 1.2 o precedente di Asterisk, pertanto senza dover più programmare dialplans nel formato extensions.conf, anche continuando ad utilizzare vecchie versioni.

• -n: Non visualizza le chiamate di funzione necessarie a costruire le extensions in asterisk.

• -q: (implica -n). Visualizza solamente messaggi di warning ed errore.

Send post as PDF to

A conforto dei cittadini svedesi, le loro istituzioni hanno avuto almeno la dignità di non prestarsi, se non forse per “atto dovuto” alla ridicolaggine di accuse pretestuose.
Alla fine resta solo un dubbio: Feltri è anche consulente della NSA?

Send post as PDF to

1. Selezionare l’opzione di menu All Protocols -> Traffic.
2. Nell’elenco a discesa a sinistra, Hosts, selezionare Local Only
3. Nell’elenco a discesa a destra, Data, selezionare Received Only
4. Cliccare sulla VLAN cui si è interessati oppure su ALL per osservare il traffico per tutte le VLANs.
5. Cliccare sulla intestazione della colonna Data per un ordinamento per dati e percentuale.

Ribaltando questo concetto, se un host della rete locale sta inviando più traffico di quanto ne riceva, allora quell’ host sta offrendo servizi “server”  di qualche tipo. Potrebbe trattarsi di un web server, un host P2P cha sta condividendo dei dati mentre altri ne stanno effettuando il download, un FTP server ecc.
Un’altra pagina che può fornire rilevanti informazioni specifiche per il protocollo IP (ntop supporta IPX, AppleTalk ed altri protocolli) è la opzione di menu IP:Traffic Directions:Local to Remote, che esprime in una tabella, per ciascun host locale, la quantità di traffico inviato e/o ricevuto da remoto. Assicuriamoci sempre di effettuare l’ordinamento in base alla colonna Data.

Quali Websites ottengono la maggior parte del traffico da parte della mia azienda?
Seguendo ancora la logica vista in precedenza, i websites più popolari sono quelli che ricevono il maggior ammontare di dati da parte degli utenti locali.
Come esempio, si supponga che ognuno, arrivando in ufficio, si colleghi a Google per consultare la propria email. Di conseguenza gli indirizzi IP che si riferiscono al servizio Gmail riceverà molte richieste. Per generare un elenco di tali websites, si può procedere come segue:

1. Selezionare l’opzione di menu All Protocols -> Traffic.
2. Nell’elenco a discesa a sinistra, Hosts, selezionare Remote Only
3. Nell’elenco a discesa a destra, Data, selezionare Received Only
4. Cliccare sulla VLAN cui si è interessati oppure su ALL per osservare il traffico per tutte le VLANs.
5. Cliccare sulla intestazione della colonna Data per un ordinamento per dati e percentuale.

Quale traffico proveniente da Websites consuma la maggior parte della mia banda?
Si potrebbe necessitare di tale informazione allo scopo di implementare il caching sul proxy server o per bloccare l’accesso a noti divoratori di banda come i siti di download. Ciò cui siamo interessati è quanti dati l’host remoto abbia inviato alla nostra rete.

1. Selezionare l’opzione di menu All Protocols -> Traffic.
2. Nell’elenco a discesa a sinistra, Hosts, selezionare Remote Only
3. Nell’elenco a discesa a destra, Data, selezionare Sent Only
4. Cliccare sulla VLAN cui si è interessati oppure su ALL per osservare il traffico per tutte le VLANs.
5. Cliccare sulla intestazione della colonna Data per un ordinamento per dati e percentuale.

I dati sul traffico remoto possono anche essere ottenuti specificamente per il protocollo IP scegliendo IP -> Traffic Directions -> Remote to Local e quindi effettuare l’ordinamento per Data Sent o Data Received.

Quali applicazioni vengono usate?
In questo contesto “applicazioni” si riferisce ad applicazioni di rete, essenzialmente identificate dalle porte che utilizzano. DNS ad esempio è una applicazione il cui componente server è sempre in ascolto sulla porta 53 UDP. Sebbene la maggior parte dei programmi peer-to-peer per default usa uno specifico range di porte, essi possono anche usare le porte di altri protocolli noti, come http (80), per cui ntop fa riferimento alle informazioni contenute negli header per rilevare i programmi p2p.
Le seguenti pagine di ntop pages forniscono tale informazione:

• Global TCP/UDP Protocol Distribution, accessibile dalla pagina Summary -> Traffic, mostra i grafici relativi alle più note applicazioni rilevate dal momento in cui ntop è stato avviato.

• Accumulated and Historical Views in fondo alla pagina Summary -> Traffic offre pure un grafico del consumo di banda per intervallo di tempo relativo a ciascuna applicazione (protocollo).

• La pagina TCP/UDP: Local Protocol Usage accessibile dalla opzione di menu IP -> Local -> Ports Used elenca le applicazioni servite ed usate dagli hosts locali. Per ciascuna applicazione vengono elencati i nomi o gli indirizzi IP dei clients locali così come dei server locali.

In che ora del giorno la rete viene maggiormente utilizzata?
Per rispondere a questa domanda, basta dare una occhiata alla pagina Summary -> Network Load. Nello specifico al grafico Last Day.

Effettuare un inventario della rete
Nel caso si volesse individuare quali devices eseguano quali servizi di rete, chi siano DHCP, DNS, Web servers, quali hosts siano routers etc., la pagina cui fare riferimento è Local Hosts Characterization, accessibile  IP -> Local -> Hosts Characterization.

Esportazione dei dati di traffico
Potrebbe essere desiderabile scaricare i dati correnti che ntop ha nelle sue strutture di memoria in modo da potervi applicare altri tools di analisi. Per fare ciò, occorre cliccare Utils -> Data Dump per ottenere la schermata seguente. Si può effettuare un dump dei dati relativi a hosts, subnets, host matrix anche per interfaccia. Inoltre il dump dei dati è ottenibile in differenti formati selezionabili dall’elenco a discesa.

Send post as PDF to

IP:Summary:Traffic - Visualizza una tabella che elenca, per ciascun host (IP) visto, quanti dati tale host abbia trasferito, che percentuale del traffico totale dal momento in cui ntop è entrato in funzione rappresenti, e l’ammontare di traffico inviato per alcuni protocolli chiave TCP/IP  (FTP HTTP DNS, Telnet, NBios-IP Mail, DHCP-BOOTP SNMP NNTP, NFS/AFS, VoIP X11, SSH, Gnutella, Kazaa, WinMX, DC++, eDonkey, BitTorrent, Messenger, Other, IP).
Si può visualizzare questa informazione relativamente agli hosts locali, remoti o tutti gli hosts per i dati inviati, ricevuti o sia inviati che ricevuti sia per singola VLAN che per tutte le VLANs.

IP:Summary:Multicast - Visualizza una tabella di tutti i gruppi ed origini multicast e quanti dati ciascuna origine abbia inviato o quanti dati ciascun gruppo ha ricevuto.

IP:Summary:Internet Domain - Visualizza statistiche di traffico per tutti i domini Internet (DNS). Per quanto riguarda TCP/IP, vengono mostrati i dati inviati/riecevuti in kilobytes o come una percentuale per TCP, UDP e per entrambi. Per quanto riguarda ICMP, viene mostrato il traffico inviato/ricevuto per IPv4 ed IPv6.

IP:Summary:ASs - Visualizza un elenco degli Autonomous Systems BGP che il vostro traffico attraversa.

IP:Summary:Host Communities - Fornisce informazioni sul traffico aggregato di gruppi predefiniti di host. Cliccando su un qualsiasi cluster si ottengono le statistiche di traffico degli hosts componenti.

IP:Summary:Distribution - Visualizza un grafico a torta che rappresenta l’ammontare relativo a traffico locale, locale verso remoto, e remoto verso locale. Per ciascuna di queste categorie di traffico, una tabella fornisce maggiori dettagli ulteriormente suddivisa per protocollo IP.

IP:Traffic Directions:Local to Local - Visualizza per ciascun host locale (DNS o NetBIOS name) l’indirizzo IP così come i dati inviati e ricevuti sia in kilobytes che come percentuale. Le piccole icone presenti nella colonna degli hosts costituiscono degli indicatori dei servizi (http, mail, p2p etc) così come le pandierine sullo status. In fondo alla pagina vi è una piccola tabella che sommarizza il traffico totale dei dati inviati e ricevuti così come la banda usata per il periodo di attività di ntop.

IP:Traffic Directions:Local to Remote - Fornisce le stesse informazioni, ma con statistiche limitate al traffico originato da hosts locali e destinato a hosts remoti.

IP:Traffic Directions:Remote to Local - Fornisce le stesse informazioni, ma con statistiche limitate al traffico originato da hosts remoti e destinato a hosts locali.

IP:Traffic Directions:Remote to Remote - Fornisce le stesse informazioni, ma con statistiche limitate al traffico originato da hosts remoti e destinato a hosts remoti.

IP:Local:Ports Used - Visualizza una tabella che elenca per ogni servizio (es. ftp, telnet, ed http), come identificate dalle porte TCP/UDP port, l’indirizzo IP dei clients e dei servers che usano quel servizio.

IP:Local:Active TCP/UDP Sessions.

IP:Local:Host Fingerprint - Visualizza i Sistemi Operativi degli hosts rilevati sulla rete. La accuratezza di questa feature dipende dai database per OS fingerprint usati da ettercap.

IP:Local:Host Characterization - Visualizza una tabella che identifica che tipo di device un host sia (L2 switch, gateway, printer) e che genere di servizi ospiti (VoiP NTP/DNS server, Mail, Directory, HTTP, FTP, DHCP, WINS, se l’ host stia eseguendo qualche programma peer-to-peer e se l’ host sia attivo oppure no)

IP:Local:Network Traffic Map - Traccia una mappa del traffico di rete che mostra graficamente quali hosts accedano a quali altri.

IP:Local:Local Matrix - Visualizza una matrice di hosts sulla subnet locale e quanto traffico scambiano tra loro.

Utils:RRD Alarms:Configure Thresholds
Utils:RRD Alarms:Check Now

Utils:Data Dump - Fornisce una pagina dove impostare il dump delle varie statistiche di ntop relative agli hosts rilevati in vari formati di file (text, xml, perl, python, php e json)

Utils:View Log - Questa pagina mostra gli ultimi 50 log messages di ntop con priority INFO o superiore.

La versione corrente di ntop supporta dei plug-ins, come meccanismo di estensione. All’ amministratore è consentito estendere le funzionalità di ntop con features extra. Esempi di plug-ins sono quelli relativi a ICMP, ARP/RARP e WAP. Possono venire installati opzionalmente, ed avviati selettivamente durante la inizializzazione di ntop.

Plugins:cPacket - Questo plugin viene usato per collezionare statistiche di traffico prodotto da devices cTap di cPacket. Il flusso dei dati ricevuti viene riportato come relative a  ‘NIC’ separati nei regolari reports di ntop  – proprio come interfaccie NetFlow virtuali.

Plugins:icmpWatch - Questo plugin produce un report riguardante i pacchetti ICMP che ntop ha rilevato.

Plugins:NetFlow - Questo plugin viene usato per impostare, attivare e disattivare il supporto NetFlow, con ntop come collettore NetFlow.

Plugins:RoundRobin Database - Questo plugin viene usato per impostare, attivare e disattivare il supporto di rrd in ntop.

Plugins:sFlow - Questo plugin viene usato per impostare, attivare e disattivare il supporto di sFlow in ntop.

Admin:Configure:Startup Options - Apre una pagina dove è possibile configurare le varie opzioni di avvio per ntop (figura seguente). La maggior parte delle opzioni di ntop specificabili a riga di comando hanno degli equivalenti qui.


Admin:Configure:Preferences - Apre una pagina dove è possibile impostare delle preferences per ntop. Anche qui le opzioni specificabili hanno un equivalente a riga di comando. Tipicamente, si assegna un valore di 0 per disattivare una opzione, o di 1 per attivarla.

Admin:Configure:Packet Filter - Permette di impostare una espressione filtro che definisce che tipo di traffico ntop debba analizzare.

Admin:Configure:Reset Stats - Scarica tutte le informazioni che ntop ha raccolto in memoria e fa ripartire i conteggi da zero.

Admin:Configure:Web Users - Configura l’ insieme di utenti che possono accedere all’interfaccia web di ntop (usernames e passwords)

Admin:Configure:Protect URLs - Configura l’accesso a varie pagine di ntop in base all’utente.

Admin:Shutdown - Termina l’esecuzione di ntop.

Send post as PDF to

Il programma viene attivamente sviluppato e mantenuto da Luca Deri, ricercatore e docente presso il Dipartimento di Informatica dell’Università di Pisa, ed è caratterizzato da una interfacia web integrata semplice da utilizzare, caratteristica che lo rende pertanto estremamente portabile, ed un minimo utilizzo di risorse.

Il network management è una attività molto complessa, e tale complessità, dovuta alla varietà delle tipologie di network e alla loro crescente integrazione, sta progressivamente aumentando.

Dal momento che le reti diventano progressivamente più grandi, più complesse, ed anche più eterogenee, i costi del network management crescono.
In tale scenario, tools automatici divengono essenziali strumenti di supporto, collezionando informazioni sullo stato ed il comportamento dei vari elementi di rete.

Ntop è uno dei pochi applicativi per le reti locali diffuso anche a livello mondiale, avendo saputo dimostrare nel corso degli anni di essere un tool molto affidabile per il network monitoring sia in ambito LAN (default) che WAN

Sebbene sia disponibile anche sottoforma di package precompilato per differenti distribuxioni Linux, è sicuramente preferibile effettuarne una compilazione a partire dai sorgenti, che sono disponibili sia sotto forma di tarball compresso che tramite server SVN, caso nel quale si possono ottenere così:

# mkdir /opt/tools/
# cd /opt/tools/
# svn co https://svn.ntop.org/svn/ntop/trunk/ntop

Per compilare infine ntop:

# cd ntop
# ./autogen.sh
# make
# make install

Occorre per prima cosa lanciare ./autogen.sh nella directory base (ntop) per creare lo script configure e i Makefiles.
Lo script configure risulta molto indicativo riguardo ad eventuali dipendenze assenti, come ad esempio:

*******************************************************************
*
* ERROR: gdbm header or library routines are missing
*           (yes means it was found, no means it was not found)
*
*              gdbm.h...no
*              gdbm_open() in -lgdbm...no
*
*>>> No way to proceed.
*
*???     1. Install libgdbm
*???    and Rerun ./configure
*???  or 2. Use the --with-gdbm-xxxxx= options
*
*******************************************************************

configure: error: Unable to continue... aborting ./configure

dove il problema è chiaramente dovuto all’assenza del package libgdbm-dev.

Si possono anche passare opzioni “configure” ad autogen.sh, come ad esempio in:

# ./autogen.sh --prefix=/usr/local/ntop-svn

Ntop necessita di essere avviato coi privilegi di root per poter catturare i pacchetti in transito dalle schede di rete della macchina e mettere una interfaccia in promiscuous mode.
Non appena avviato tuttavia, per default, declassa i propri privilegi a quelli dell’utente nobody (se non diversamente specificato con l’opzione –u).
È importante ricordare che lo user al quale ntop adegua i propri privilegi deve possedere gli appropriati diritti per accedere alle locazioni dove ntop archivia i propri database (cioè /usr/local/var/ntop per default).

Per impostare correttamente proprietà e diritti su tali directory:

# chown –R [ntopuser]:[ntopusergroup] /usr/local/var/ntop

Quando si installa ntop e lo siconfigura per la prima volta, è necessario impostare una password amministrativa:

# ntop --set-admin-password

oppure

# ntop –A

quindi introdurre e confermare la propria password amministrativa per ntop.

L’avvio di ntop può avvenire semplicemente invocando il comando

# ntop -d
Wed Aug 11 11:33:21 2010  NOTE: Interface merge enabled by default
Wed Aug 11 11:33:21 2010  Initializing gdbm databases
Wed Aug 11 11:33:21 2010  ntop will be started as user nobody
Wed Aug 11 11:33:21 2010  ntop v.4.0.1 (32 bit)
[...]
Wed Aug 11 11:33:21 2010  INIT: Bye bye: I’m becoming a daemon…
Wed Aug 11 11:33:21 2010  INIT: Parent process is exiting (this is normal)

e può normalmente avvenire anche come servizio con:

# /etc/init.d/ntop restart

Per conoscere l’elenco delle possibili opzioni a riga di comando previste da ntop ed il loro scopo si può dare

# ntop –h

oppure

# ntop --help


Welcome to ntop v.4.0.1 (32 bit)
[Configured on Aug 11 2010 10:04:39, built on Aug 11 2010 10:06:08]
Copyright 1998-2010 by Luca Deri <deri@ntop.org>.
Get the freshest ntop from http://www.ntop.org/

Usage: ntop [OPTION]

Basic options:
[-h             | --help]                             Display this help and exit
[-u <user>      | --user <user>]                      Userid/name to run ntop under (see man page)
[-t <number>    | --trace-level <number>]             Trace level [0-6]
[-P <path>      | --db-file-path <path>]              Path for ntop internal database files
[-Q <path>      | --spool-file-path <path>]           Path for ntop spool files
[-w <port>      | --http-server <port>]               Web server (http:) port (or address:port) to listen on
[-W <port>      | --https-server <port>]              Web server (https:) port (or address:port) to listen on

Advanced options:
[-4             | --ipv4]                             Use IPv4 connections
[-6             | --ipv6]                             Use IPv6 connections
[...]

L’accesso ad ntop può avvenire sia in modalità interattiva che in web mode.
Per accedere ad ntop attraverso l’interfaccia web occorre puntare alla URL http://localhost:3000 o più genericamente http://nnn.nnn.nnn.nnn:3000 nel caso in cui l’accesso avvenga da una macchina diversa da quella dove ntop è in esecuzione.
L’interfaccia web è molto semplice ma lineare, con un menu, nell’area superiore, così strutturato gerarchicamente:

About:What is ntop? (Cosa è e a cosa serve ntop)
About:Il blog di ntop (http://www.ntop.org/blog/)
About:Crediti (altri sviluppatori hanno contribuito al progetto)
About:Make a donation (fate finta di non aver capito, mi raccomando!)
About:Documentazione on line (man pages, FAQ, anche un tutorial python)
About:Mostra configurazione (figura seguente) ntop0.png
About:Riporta un problema

Summary:Traffico. Questa pagina, che è in realtà quella che si apre per prima nel browser (figura seguente),

presenta informazioni tramite una serie di tabelle e grafici riferiti a:

Statistiche globali sul traffico.
Report del traffico per interfaccia attiva.
Distribuzione globale per protocollo (figura seguente).
Distribuzione globale relativa al protocollo TCP/UDP.
Distribuzione del traffico per porte TCP/UDP (Last Minute View)

Summary:Hosts. Fornisce informazioni su tutti gli hosts visti (figura precedente). Il traffico mostrato per ciascun host può essere espresso in byte o pacchetti. I valori di bandwidth sono la percentuale dei bytes total che ntop ha visto sull’interfaccia, ed il totale dei valori NON sarà del 100% dal momento che il traffico locale verrà contato due volte (una volta come inviato e l’altra come ricevuto). La banda per il traffico inviato e ricevuto viene mostrata attraverso barre diversamente colorate.
Cliccando su una icona accanto al nome host se ne ottiene la geolocalizzazione (figura seguente).

Summary:Carico di rete (Network Load). Mostra dei grafici relativi al network throughput degli ultimi 10 minuti, 1 ora, 1 giorno ed 1 mese (figura successiva).

Cliccando sul graph viene visualizzata una tabella dei 3 indirizzi più attivi (cliccando sui grafici Last 10 minute o Last Hour) ogni minuto (figura seguente), oppure ogni ora (cliccando sul grafici Last Day).

Summary:Traffic Map:Region Map. Fornisce informazioni sugli hosts presenti in ciascuna regione (Stati Uniti, Italia, Cina).
Summary:Traffic Map:Host Map. Geolocalizza tutti gli hosts rilevati (figura seguente).

Summary:Network Flows. Fornisce informazioni si qualsiasi specifica regola di flusso, user-defined.

All Protocols:Traffic. Visualizza una tabella che elenca per ciascun host rilevato, quanti dati quell’ host abbia trasferito, quale percentuale del traffico totale rappresenta dal momento in cui ntop è andato in esecuzione, e la quantità di traffico inviato da alcuni protocolli chiave (TCP, UDP, ICMP, ICMPv6, DLC, IPC, RARP, Appletalk, GRE, IPv6, OSPF, IPSec ed altri protocolli).
All Protocols: Throughput. Visualizza una tabella relativa al network throughput. Si possono limitare tali informazioni solamente agli hosts locali oppure solo agli hosts remoti oppure tutti gli hosts e per ciascuna opzione, si possono vedere i dati inviati, i dati ricevuti o la totalità dei data sia inviati che ricevuti.
All Protocols:Activity. Visualizza una tabella che mostra il traffico orario per host. Il valore percentuale per un dato host è il traffico per quell’host durante quell’ora diviso il traffico totale per quell’ host nelle ultime 24 ore.

Riprenderemo il discorso la prossima volta

Send post as PDF to

[jamendo]
mode = custom
application=/usr/bin/mpg123 -q -s --mono -r 8000 -f 8192 -b 0 \
            http://api.jamendo.com/get2/stream/track/redirect?id=552462

e in extension conf, cioè nel dialplan, una invocazione tipo questa:

exten => 5000,1,Answer
exten => 5000,2,MusicOnHold(jamendo)

comportandosi di fatto come file mp3 (se si tralascia infatti la codifica ogg)

Un’ altra ottima soluzione è quella di utilizzare come origine una stazione radio, come quella ottima di musica ambient riferita dalla url http://ubuntu.hbr1.com:19800/ambient.ogg, e generare dei file sonori (ad esempio di 5 Mbyte) tramite un comando come:

# /usr/bin/ogg123 -q -b 512 -p 64 -d wav -f - http://ubuntu.hbr1.com:19800/ambient.ogg \

  | sox -t wav - -r 8000 -c 1 -t wav /var/lib/asterisk/moh/ambient/ambient.wav vol 0.3

da posizionarsi in una directory apposita (qui /var/lib/asterisk/moh/ambient) cui fare riferimento, in musiconhold.conf, con una sezione del tipo:

[ambient]
mode=files
directory=moh/ambient/

e in extension conf, con una invocazione come:

exten => 6000,1,Answer
exten => 6000,2,MusicOnHold(ambient)


Send post as PDF to

La vulnerabilità consiste nel fatto che non esiste alcuna reciproca autenticazione tra un terminale mobile e la rete. Solo il primo si autentica, inviando alla cella con cui si associa il proprio IMSI (International Mobile Subscriber Identity), un numero di 15 cifre memorizzato nella SIM.
La mancanza di reciproca autenticazione apre le porte ad attacchi di tipo Man-in-the-Middle (MitM).
Non sarebbe un grosso problema, dato che il traffico viene crittato, se non fosse che il protocollo GSM consente alle celle la possibilità di forzare i cellulari connessi a disattivare la crittografia.
L’attacco MitM può avvenire in una situazione nella quale un elemento hardware sia in grado di interagire coi cellulari GSM con le stesse modalità con cui lo fa la cella del provider (un device di questo tipo è comunemente noto come IMSI-catcher).
Come conseguenza dell’impiego di un IMSI-catcher, informazioni sensibili come IMSI, IMEI, e numeri di telefono possono venire catturati. È anche possibile la registrazione dell’ audio di una chiamata (in una sola direzione).

Ne ha dato una pubblica dimostrazione, nell’ ambito dell’ultimo Defcon, il ricercatore Chris Paget, che per l’occasione ha allestito un IMSI-catcher del costo di 1500 dollari (per il transceiver, due antenne direzionali, un notebook) e utilizzando, per la parte software OpenBTS (un GSM access point software), ed Asterisk come gateway tra rete GSM e rete VoIP.

Nel corso della dimostrazione almeno 30 telefoni si sono collegati alla “cella”. Sono stati registrati i relativi IMSI, IMEI, tutti i numeri che sono stati chiamati, e, ovviamente, l’audio di tutte le chiamate effettuate (per un totale di 17 chiamate).
Nessuno dei proprietari dei cellulari ha notato alcunché di strano, nonostante la mancanza di crittografia sulla rete.

Le slides dell’evento sono disponibili in formato Open Office a questo indirizzo.

Send post as PDF to

La conoscenza di tali limiti è di grande utilità nella implementazione di un PBX in ambienti estesi.

Questo test prevede, per il suo svolgimento, di una macchina Asterisk (IP 192.168.1.10), e di una seconda macchina (IP 192.168.1.12), connessa alla precedente in rete locale ethernet, sulla quale viene invece eseguito sipp, un tool Open Source per la generazione di traffico per il protocollo SIP.

Sul server asterisk, è necessaria la presenza di una sezione come la seguente nel file extensions.conf:

[test_sipp]
exten => _X.,1,Answer
exten => _X.,n,Background(demo-instruct)
exten => _X.,n,Hangup

oppure come la seguente nel file extensions.ael:

context test_sipp
{
        _X. => {
                Answer();
                while (1) {
                        Background(demo-instruct);
                }
                Hangup();
        }
}

Sostanzialmente, ogni chiamata SIP in ingresso riceve risposta, ed il chiamante ascolta un file sonoro (per comodità viene utilizzato il file sonoro demo-instruct, presente nel package di base). In particolare, il test delega al chiamante l’hangup, consentendo in tal modo al tool sipp di predeterminare
la durata di ciascuna chiamata.

Nel file sip.conf è presente una sezione simile:

[sipp01]
type=friend
context=test_sipp
host=192.168.1.12
user=sipp
directmedia=no
disallow=all
allow=ulaw

con una configurazione dello UAC minimale (nessuna autenticazione e ulaw come codec utilizzato).

Per misurare l’ impatto del traffico in ingresso sulla macchina Asterisk, è sufficiente una utility di sistema come vmstat, che offre una visuale della utilizzazione della CPU da parte di Asterisk.
Il sintomo tipico del raggiungimento di valori limite da parte di Asterisk consiste nella totale utilizzazione della CPU (100%) e nella conseguente impossibilità di aumentare il carico di lavoro, cosa che si manifesta con timeouts ed altri problemi, fino al blocco totale.

È consigliabile effettuare il test in due modalità differenti:

La capacità di processare chiamate viene misurata con chiamate di durata estremamente breve, come in:

# sipp -sn uac 192.168.1.10 -i 192.168.1.12 -s 22 -d 100 -l 250

dove a sipp viene impartito di chiamare la macchina Asterisk (192.168.1.10) alla extension 22, con chiamate ciascuna della durata di 0.1 secondi, e con un limite di 250 chiamate simultanee.
Le chiamate simultanee risulteranno la frequenza per secondo delle chiamate entranti diviso la durata di ciascuna chiamata, perciò 1 chiamata simultanea a 10 calls/sec, e 50 a 500 calls/sec.
Il limite impostato a 250 implica che non si intende superare il limite di 2500 calls/sec in fase di test.

Sipp opera inizialmente con 10 calls/sec, ed è possibile aumentare granularmente tale frequenza tramite i tasti ‘*’ o ‘+’.
Quando si è prossimi al 100% nell’utilizzo della CPU sul server Asterisk, si avrà raggiunto il limite massimo.

Le chiamate simultanee possono invece venire quantificate con chiamate di lunga durata. Ad esempio:

# sipp -sn uac 192.168.1.10 -i 192.168.1.12 -s 22 -d 90000 -l 270

istruisce sipp a effettuare chiamate verso il server Asterisk della durata di un minuto e mezzo (90 sec).
Il numero di chiamate simultanee crescerà fino a raggiungere il limite stabilito di 270.
Se Asterisk sopravvive fino al raggiungimento di tale valore senza che la CPU raggiunga il 100% di utilizzo, si può interrompere il test e riprovare con un valore (-l) più alto.

Send post as PDF to