Lavoro di semestre 7 marzo Agente SNMP su TINI. Docente responsabile: Ivan Defilippis Committente: Lorenzo Morellini

Transcript

1 Lavoro di semestre 7 marzo 2004 Agente SNMP su TINI Alan Küng Alan Dalessi Docente responsabile: Ivan Defilippis Committente: Lorenzo Morellini

2 Sommario La ditta Mandozzi Elettronica produce gli apparecchi Combimux per le linee 2Mbit, che vengono controllati via una linea seriale e tramite un apposita superficie di comando su PC Windows. Ultimamente ha cominciato ad interessarsi ad una scheda WAN, con interfaccia Ethernet. Questa scheda si chiama TINI ed è basata su di un processore ds80c400. Per rispondere ai bisogni di parte della clientela, la ditta Mandozzi sta valutando la possibilità di pilotare i suoi Combimux via LAN con SNMP utilizzando questa scheda. Abstract The firm Mandozzi Elettronica produces the instruments Combimux for the lines 2Mbit, that are checked away from a serial line and through a special surface of command on PC Windows. Lately they started to look for a WAN card, with Ethernet interface. This card is called TINI and is based on a ds80c400 processor. To answer to the needs of part of the clients the firm Mandozzi is studiyng the possibility to pilot his Combimuxes via LAN with SNMP using this card.

3 INDICE INDICE Indice 1 Definizione del progetto Obiettivo Compiti Schema generale Il protocollo SNMP Introduzione SNMP Framework SNMP Community Messaggi Structure management information (SMI) Management information base (MIB) Il Combimux Introduzione RS TINI (Tiny InterNet Interface) La scheda La Java virtual machine Il sistema operativo Slush: La shell di TINI A proposito di Slush Come accedere a Slush Utenti Comandi Programmare su TINI Introduzione Compilare un programma in Java Utilizzo della seriale serial Agente SNMP su TINI Introduzione L agente Il Processo SNMP Il Processo Combimux Avvio programma compilato marzo 2004 Küng Alan, Dalessi Alan pagina 3

4 INDICE INDICE 6.3 Il file di configurazione Prestazioni Il manager SNMP Introduzione Interfaccia grafica in VB Net-SNMP snmpget Net-SNMP snmpset Istruzioni in breve Sviluppi futuri 37 8 Allegati 39 pagina 4 Küng Alan, Dalessi Alan 7 marzo 2004

5 ELENCO DELLE FIGURE ELENCO DELLE FIGURE Elenco delle figure 1.1 Schema a blocchi del progetto Esempio di albero MIB Gli otto led di controllo dello status La scheda TINI Struttura software di TINI Il jumper J Schema generale dell agente L interfaccia grafica dell SNMP manager Menu file-> apri Controlli set e get nel caso di un tipo R/W Controllo IP Controllo risposta Attivazione della richiesta di status Controlli status COMBIMUX marzo 2004 Küng Alan, Dalessi Alan pagina 5

6 ELENCO DELLE FIGURE ELENCO DELLE FIGURE pagina 6 Küng Alan, Dalessi Alan 7 marzo 2004

7 CAPITOLO 1. DEFINIZIONE DEL PROGETTO Capitolo 1 Definizione del progetto 1.1 Obiettivo Si tratta di implementare sulla scheda TINI un SNMP Agent minimo, in grado di comunicare serialmente con un apparecchio Combimux. 1.2 Compiti 1. Studio del problema e scelta del SNMP Manager. Si tratta in questa fase di scegliere un SNMP Manager, che verrà poi utilizzato per il resto del progetto. A questo scopo un qualsiasi SNMP Manager può essere preso in considerazione, a condizione che possa essere facilmente configurato per il bisogno di questo progetto (SNMPv2). 2. Utensili di sviluppo del SNMP Agent. Gli utensili devono essere scelti tenendo conto del hardware a disposizione (TINI con ds80c400) e della necessità di implementare un SNMPv2. 3. Implementazione del SNMP Agent. L agente dovrà essere in grado di rispondere a delle richieste SNMPv2 standard e di comunicare tramite seriale con un apparecchio Combimux a cui si potrà richiedere lo stato di alcuni led, il metodo di sincronia e inviare un comando di reset. Si cercherà di implementare unicamente le funzioni Agent necessarie, mantenendo la compatibilità con il SNMP Manager. 4. Messa a punto di un manager SNMP su PC. Il manager dovrà essere in grado di inviare richieste ad un agente SNMP standard. 7 marzo 2004 Küng Alan, Dalessi Alan pagina 7

8 1.3. Schema generale CAPITOLO 1. DEFINIZIONE DEL PROGETTO 1.3 Schema generale Figura 1.1: Schema a blocchi del progetto. pagina 8 Küng Alan, Dalessi Alan 7 marzo 2004

9 CAPITOLO 2. IL PROTOCOLLO SNMP Capitolo 2 Il protocollo SNMP Questo capitolo si riferisce al documento Protocollo SNMP Overview del sito OpenSkills ( 2.1 Introduzione SNMP è un protocollo utilizzato per la gestione dell infrastruttura di rete. Simple Network Managment Protocol (SNMP), permette il monitoraggio (statistiche sullo stato dei sistemi) ed il controllo (modifica delle impostazioni) di dispositivi di rete quali Server, Router, Switch, Hub ecc. Grazie ad SNMP è possibile sapere throughput, il carico, dati sulle interfacce di rete, e prestazioni di un sistema. E generalmente utilizzato su reti TCP/IP ma può essere implementato anche su reti IPX o AppleTalk. SNMP è passato attraverso alcune revisioni fino all attuale versione 3: SNMPv1: descritto nelle RFC rappresenta la prima versione, utilizza l invio dei nomi di community (utilizzati come password) in chiaro. SNMPv2: descritto nelle RFC in cui sono state aggiunte nuove funzionalità tra cui la crittografia tramite MD5 SNMPv3: descritto nelle RFC è lo standard finale, ma al momento raramente utilizzato 2.2 SNMP Framework Sostanzialmente un framework SNMP è composto da una o più Stazioni di Gestione (Management Station) e dagli agenti SNMP (SNMP Agent) in funzione sui device di rete. Le Management Station interrogano gli agent i quali inviano le informazioni richieste sul device. Solitamente gli agent SNMP di un apparato di rete sono implementati nel firmware dello stesso, mentre per quanto riguarda i server, si tratta di servizi software. Gli oggetti gestiti dagli agent, sono raccolti, in ogni device, in un database chiamato MIB (Management Information Base) secondo la struttura definita nella SMI (Structure Management Information). Esiste un caso particolare dove l apparato di rete non viene interrogato, ma è esso stesso 7 marzo 2004 Küng Alan, Dalessi Alan pagina 9

10 2.3. SNMP Community CAPITOLO 2. IL PROTOCOLLO SNMP a generare il messaggio ed inviarlo alle Management Station. E infatti possibile configurare gli agent in modo da inviare un particolare messaggio al verificarsi di determinati eventi ovvero impostare le cosidette trap. Grazie all impostazione delle trap è possibile ad esempio sapere quando un interfaccia di rete smette di funzionare, in quanto al verificarsi del guasto, l agent SNMP che esegue il monitoraggio dell apparato invia alla Management Station un messaggio che identifica il problema. SNMP utilizza come protocollo di trasmissione UDP in modo da ottenere migliori performance e minore overhead della rete. In particolare viene utilizzata la porta UDP 161 per le interrogazioni e le risposte, e la porta UDP 162 come destinazione dei messaggi trap SNMP generate dagli agent SNMP. 2.3 SNMP Community L insieme degli apparati di rete gestiti da SNMP appartengono ad una comunità (community). La comunità rappresenta un identificativo che permette di garantire la sicurezza delle interrogazioni SNMP. Un agent SNMP risponde solo alla richieste di informazioni effettuate da una Management Station appartenente alla stessa comunità. I nomi di comunità sono formati da 32 caratteri e sono di tipo case sensitive. Esistono tre tipi di comunità: monitor: Permette di lavorare in sola lettura, quindi di effettuare solamente interrogazioni agli agent (il cui nome di comunità deve corrisponde a quello della management station che ne ha fatto la richiesta). control: Permette tramite gli agent SNMP di effettuare delle operazioni in lettura/scrittura sul dispositivo, quindi di variarne delle impostazioni sempre previo controllo di sicurezza. trap: Permette ad un agent di inviare un messaggio trap SNMP alla management station secondo la propria configurazione. Spesso i nomi di community di default predefiniti sono public per le comunità di sola lettura e write o private per quelle in lettura/scrittura. Ovviamente è bene modifcare queste impostazioni di default per motivi di sicurezza. 2.4 Messaggi SNMP utilizza sei tipi di messaggi di base per svolgere il proprio lavoro. Ogni messaggio è definito in PDU (Protocol Data Unit) separate, e precisamente: GetRequest: è utilizzata per interrogare un MIB su un agent SNMP GetNextRequest: è utilizzata per leggere in modo sequenziale un MIB GetBulk: permette di leggere un MIB con un unica richiesta anzichè utilizzare più messaggi GetNextRequest SetRequest: modifica il valore all interno di un MIB acceddibile in lettura/scrittura pagina 10 Küng Alan, Dalessi Alan 7 marzo 2004

11 CAPITOLO 2. IL PROTOCOLLO SNMP 2.4. Messaggi GetResponse: identifica la risposta da parte di un agent SNMP ad un interrogazione di una management station Trap: permette all agent di inviare un messaggio al verificarsi di un determinato evento; Alcune trap sono predefinite: coldstart: generata quando l agente SNMP si reinizializza e la configurazione è stata cambiata (Es. reboot del sistema) warmstart: generata quando l agente SNMP si reinizializza ma senza cambiamenti nella configurazione linkdown: generata quando il collegamento con l agent non funziona correttamente linkup: generata quando il collegamento con l agent viene ripristinato authenticationfailure: generata da un autenticazione con l agent non andata a buon fine (Es. nome di comunità errato) egpneighborloss: generata da problemi di EGP (Exterior Gateway Protocol - utilizzato dai router) enterprisespecific: evento definito dal produttore del device 7 marzo 2004 Küng Alan, Dalessi Alan pagina 11

12 2.5. Structure management information (SMI) CAPITOLO 2. IL PROTOCOLLO SNMP 2.5 Structure management information (SMI) Structure Mangement Information definisce in modo standard come devono essere strutturate le informazioni e la loro gerarchia per essere inserite nel database MIB e quindi gestite da una manager SNMP. La gerarchia degli oggetti, è ad albero: Ogni oggetto della gerarchia viene identificato in modo univoco, attraverso il suo percorso nell albero, la variable Hostname per esempio è identificata da oppure iso.org.dod.internet.mgmt.mib-2.system Gli oggetti sono definiti tramite la sinstassi ASN.1 (Abstract Syntax Notation One), la quale permette di non avere ambiguità tra funzioni e proprietà dell oggetto definito. Figura 2.1: Esempio di albero MIB. 2.6 Management information base (MIB) La management Information Base, è una base di dati contenente tutte le informazioni gestite dall agent SNMP che è in funzione sulla device monitorata. Gli oggetti all interno di una MIB vengono definiti in base alle strutture SMI. Attualmente lo standard utilizzato è la MIB-II. All interno di ogni MIB gli oggetti sono suddivisi in categorie, in particolare: System: contiene informazioni di carattere generale sul device di rete Interfaces: contiene le informazioni relative alle interfacce di rete Address Translation: contiene informazioni relative alla conversioni degli indirizzi (Es. da logico a fisico), esiste per compatibilà con MIB-I pagina 12 Küng Alan, Dalessi Alan 7 marzo 2004

13 CAPITOLO 2. IL PROTOCOLLO SNMP 2.6. Management information base (MIB) Ip: contiene informazioni relative al protocollo IP Icmp: contiene informazioni relative al protocollo ICMP Tcp: contiene informazioni relative al protocollo TCP. Gli oggetti di questo gruppo esistono solo per la durate della sessione TCP Udp: contiene informazioni relative al protocollo UDP Egp: contiene informazioni relative al protocollo EGP (protocollo utilizzato da un router per scambiare informazioni tra Autonomous System) Transmission: sperimentale, contiene informazione sui mezzi trasmissione utilizzato da ogni interfaccia di rete Snmp: contiene informazioni relative al protocollo SNMP OID: per OID intendiamo il percorso all interno dell albero MIB. 7 marzo 2004 Küng Alan, Dalessi Alan pagina 13

14 2.6. Management information base (MIB) CAPITOLO 2. IL PROTOCOLLO SNMP pagina 14 Küng Alan, Dalessi Alan 7 marzo 2004

15 CAPITOLO 3. IL COMBIMUX Capitolo 3 Il Combimux 3.1 Introduzione È una versione ristretta del COMBIMUX DT99, questo apparecchio e un sistema universale che permette l emissione di segnali audio e dati tramite canali a 2 Mbps. Possiede due slot da 19 pollici per l inserimento di moduli I/O aggiuntivi che possono essere inseriti anche sotto tensione. Il COMBIMUX è configurabile da PC tramite seriale e l apposito software COMBISOFT. Può essere messo in cascata con altri apparecchi in modo da permettere l aumento delle interfacce audio. Nel nostro caso abbiamo sfruttato la porta RS232 per effettuare richieste ed inviare comandi al COMBIMUX tramite il suo protocollo; in questo modo possiamo sapere ed impostare il suo stato. 3.2 RS232 Il collegamento RS232 è impostato a baud, 8 bit data, 1 stop, no parity. I messaggi sono dei telegrammi che cominciano con il byte 0xE0 e terminano con 0xE1. Ad ogni telegramma ricevuto, il Combimux risponde, sempre che l intestazione del telegramma sia valida. Ogni telegramma contiene la destinazione, la sorgente, la lunghezza, i dati ed un CRC 16 bits. Vediamo alcuni esempi di messaggi a cui il Combimux è in grado di rispondere: RESET Questo messaggio chiede al Combimux di eseguire un reset. Da Host a Combimux: 0xE0 0x03 0x10 0x01 0x00 0x01 0xB0 0xA5 0xE1 Risposta del Combimux: 0xE0 0x10 0x03 0x02 0x00 0xF0 0x01 0xFB 0x03 0xE1 STATUS (delle linee di allarme) Da Host a Combimux: 0xE0 0x03 0x10 0x01 0x00 0x83 0xAA 0x02 0xE1 Risposta del Combimux: 0xE0 0x03 0x03 0x?? 0x00 0x83 0xii 0xjj 0xkk... 0xE1 La lunghezza della risposta ed il valore 0x?? dipendono dalla versione del programma nel controller del Combimux. Il valore importante é 0xjj. Il Combimux dispone di un uscita di allarmi con 8 contatti relais, e questo byte indica lo status degli 8 contatti. Vediamo adesso due esempi di richiesta dello status. Per eseguire la seconda prova abbiamo inserito nella porta DS2 del Combimux una semplice chiave che simula il collagamento 7 marzo 2004 Küng Alan, Dalessi Alan pagina 15

16 3.2. RS232 CAPITOLO 3. IL COMBIMUX di una linea 2MBIT. Risposta con DS2 LOOP inserito: 0xE0 0x03 0x03 0x05 0x00 0xF0 0x83 0x1C 0x20 0xFF 0x14 0x79 0xE1 Risposta senza DS2 LOOP inserito: 0xE0 0x03 0x03 0x05 0x00 0xF0 0x83 0x1C 0x24 0xFF 0x14 0x79 0xE1 SINCRO(sincronia) Figura 3.1: Gli otto led di controllo dello status. Il Combimux può assumere due stati di sincronismo; FreeRun e DS2. Inviando un messaggio di SINCRO possiamo chiedere al Combimux in quale stato è impostato in quel momento. Lettura del modo di sincronismo: Da Host a Combimux: 0xE1 0x03 0x10 0x01 0x00 0x52 0xAE 0xC5 0xE1 Risposta del Combimux: 0xE1 0x10 0x03 0x03 0x00 0xF0 0x52 0xjj... 0xE1 Sul frontale dell apparecchio ci sono, tra gli altri, due LEDs verdi, PLL e DS2. Impostando il modo di sincronismo FreeRun, il LED PLL si accende, e DS2 resta spento. Impostando il modo di sincronismo DS2 il LED DS2 si accende ed il LED PLL si accende solo se la PLL interna è sincronizzata sul segnale 2Mbit in entrata. Abbiamo anche la possibilità di inviare un messaggio per imporre al Combimux di impostare un determinato stato di sincronismo. Impostazione del modo FreeRun: 0xE0 0x03 0x10 0x02 0x00 0x12 0x00 0x11 0x2F 0xE1 Impostazione del modo DS2: 0xE0 0x03 0x10 0x02 0x00 0x12 0x03 0x81 0x1D 0xE1 dove jj é il modo (0x00 per FreeRun e 0x03 per DS2). pagina 16 Küng Alan, Dalessi Alan 7 marzo 2004

17 CAPITOLO 4. TINI (TINY INTERNET INTERFACE) Capitolo 4 TINI (Tiny InterNet Interface) 4.1 La scheda TINI1 e un sistema embedded sviluppato dalla Dallas Semiconductor2. Comprende una serie di porte I/O tra cui seriali, un interfaccia ethernet e pieno supporto per TCP/IP. Figura 4.1: La scheda TINI 4.2 La Java virtual machine TINI dispone e poggia tutta la sua architettura su di una Java virtual machine in grado di eseguire programmi sviluppati in Java. Questa virtual machine e stata otimizzata in modo da eseguire le applicazioni nel modo piu efficace possibile ed e in grado di comunicare con la memoria, le porte seriali, ethernet e altri specifici PIN. 1 2 TINI: Tiny InterNet Interface ( 7 marzo 2004 Ku ng Alan, Dalessi Alan pagina 17

18 4.3. Il sistema operativo CAPITOLO 4. TINI (TINY INTERNET INTERFACE) Figura 4.2: Struttura software di TINI 4.3 Il sistema operativo Il sistema operativo (TINI OS), pur essendo molto ridotto, mette a disposizione molti servizi di base come la gestione dei task, un file system, gestione della memoria e gestione dell I/O. E stato sviluppato ed ottimizzato per eseguire istanze multiple di un interprete Java. Questo permette al sistema operativo di lanciare ed eseguire più processi Java in parallelo passando continuamente da un task all altro ogni 4ms. Ad eccezione del garbage collector tutti i task gestiti da TINI OS sono dei task Java. 4.4 Slush: La shell di TINI A proposito di Slush TINI mette a disposizione una shell (anch essa sviluppata in Java) di nome Slush. Slush è una shell simile a quelle presenti in ambiente UNIX e permette di gestire i file contenuti nella memoria di TINI, di lanciare processi Java, di attivare server di tipo ftp e telnet. pagina 18 Küng Alan, Dalessi Alan 7 marzo 2004

19 CAPITOLO 4. TINI (TINY INTERNET INTERFACE) 4.4. Slush: La shell di TINI Come accedere a Slush Se Slush è installato correttamente possiamo accedervi utilizzando la porta seriale e il programma TiniTalk 3 oppure tramite la porta ethernet utilizzando Telnet (se si desidera accedere come utente) o ftp (se si desidera copiare dei file da/verso tini). Da notare che prima di accedere tramite telnet o ftp bisogna assicurarsi che i servizi su TINI siano attivati e che la scheda disponga di un indirizzo IP. Per verificare l IP della scheda utilizziamo il comando ipconfig, comando che possiamo utilizzare anche per impostare l indirizzo e la relativa sub net mask. Per un collegamento diretto ad un PC tramite Ethernet dobbiamo utilizzare un cavo incrociato e impostare l ip del PC in modo che appartenga alla stessa famiglia di ip della scheda. Un esempio per un collegamento diretto tra PC e TINI: Utenti Configurazione IP PC Configurazione IP TINI Indirizzo IP: Indirizzo IP: Sub net mask: Subnet mask: Slush, essendo un sistema multi utente, permette di creare e gestire diversi utenti. Di default Slush mette a disposizione due utenti: l utente guest e l utente root. L accesso come utente guest permette di eseguire solo determinati file e comandi. L utente root, invece, non ha restrizioni per quanto riguarda i permessi ed è in grado di eseguire/cancellare tutti i file e comandi Comandi Utente guest root Password guest tini La maggior parte dei comandi rispecchiano quelli standard di una shell di UNIX come ls, pwd, etc. Riportiamo solo alcuni comandi che abbiamo avuto modo di utilizzare frequentemente: ipconfig Mostra ed imposta le configurazioni ethernet. stats Mostra informazioni sulla memoria disponibile e sullo stato dei server. gc Esegue il garbage collector liberando la memoria inutilizzata. stopserver Disattiva il server specifico. Ad esempio con il flag -s disattiviamo il server della seriale. who Mostra gli utenti attualmente collegati. java Per eseguire un applicazione java. Se si desidera mandare il processo in background terminare il comando con il carattere &. Es: java Hello.tini &. cat Mostra il contenuto di un file. Es: cat prova.txt. Per ottenere una lista di tutti i comandi digitare il comando help marzo 2004 Küng Alan, Dalessi Alan pagina 19

20 4.4. Slush: La shell di TINI CAPITOLO 4. TINI (TINY INTERNET INTERFACE) pagina 20 Küng Alan, Dalessi Alan 7 marzo 2004

21 CAPITOLO 5. PROGRAMMARE SU TINI Capitolo 5 Programmare su TINI 5.1 Introduzione La programmazione di software per un sistema embedded comporta più difficoltà che la programmazione per PC. Oggi siamo abituati ad avere microprocessori molto veloci e con grandi quantità di memoria e non ci preoccupiamo più molto di rendere il codice veloce ed efficace. Siamo anche abituati a programmare al di sopra di un solido sistema operativo che è in grado di gestire ed eseguire al meglio i nostri processi. Quando parliamo di programmazione per sistemi embedded invece bisogna confrontarsi (o scontrarsi) con dei microprocessori di frequenza molto più bassa, con memorie di capacità molto ridotte e con delle strutture hardware molto più limitate di quelle che disponiamo nelle schede madri di un normale PC. Prima di sviluppare un software bisogna quindi considerare molti fattori tra cui il linguaggio (è supportato? il codice generato sarà abbastanza veloce?) la necessità di comunicare con l esterno tramite le porte disponibili (il linguaggio me lo permette?) e la memoria a disposizione (il codice generato contiene contiene solo quello che mi serve?). Ancora oggi durante la programmazione per sistemi embedded spesso si preferisce ricorrere a linguaggi di basso livello come l assembler. Questo linguaggio permette di avere un controllo quasi completo dell hardware ma lo sviluppo risulta essere molto, a volte troppo, laborioso. Per questo motivo sono comparsi compilatori per sistemi embedded in grado di compilare programmi scritti con linguaggi a livello più alto come il basic, il C fino ai linguaggi più recenti ed orientati agli oggetti come Java. Java è un linguaggio d alto livello orientato agli oggetti molto utilizzato oggigiorno ed ha il grande vantaggio della portabilità, visto che l esecuzione di un applicazione Java non viene assegnata direttamente al microprocessore ma bensì ad una Java virtual machine che si occupa di convertire le istruzioni per il proprio microprocessore. Per contro l applicazione risulterà essere più lenta. 5.2 Compilare un programma in Java In questa sezione vedremo i passi necessari per la compilazione e l esecuzione di un programma sviluppato in Java che chiameremo arbitrariamente Hello.java. Questo esempio 7 marzo 2004 Küng Alan, Dalessi Alan pagina 21

22 5.3. Utilizzo della seriale serial0 CAPITOLO 5. PROGRAMMARE SU TINI presuppone di aver già scaricato il pacchetto di sviluppo Java TINISDK 1. Questo pacchetto contiene le classi che bisognerà utilizzare per compilazione al posto delle standard JDK API. Va precisato che non tutte le classi di Java sono supportate dalla virtual machine di TINI, riferirsi quindi alla documentazione contenuta nel pacchetto. 1. Compilazione del codice con le classi di TINI. Eseguire il comando: javac -bootclasspath d:\tini\tiniclasses.jar Hello.java 2. Copiare tutte le classi compilate in una unica cartella. Nel nostro caso decidiamo di creare una cartella di nome HelloFolder e spostiamo la nostra classe compilata precedentemente (Hello.class) in questa cartella. 3. Generazione di un eseguibile per TINI. Il prossimo passo è quello di convertire il nostro programma compilato in un eseguibile per TINI. Per fare questo abbiamo bisogno del programma TINIConvertor fornito nel pacchetto TINISDK; per utilizzarlo assicurarsi che il CLASSPATH includa l archivio tini.jar. Eseguire il comando: java TINIConvertor -f HelloFolder -o Hello.tini -d <TINI Install Dir>\firmware\tini.db Alla fine otterremo il file HelloWorld.tini che una volta copiato su TINI potremo eseguire con il comando java HelloWorld.tini oppure per un esecuzione in background con il comando java HelloWorld.tini & 5.3 Utilizzo della seriale serial0 TINI attiva di default il server della seriale sulla porta serial0. Come facciamo quindi se vogliamo sviluppare un programma che deve utilizzare questa seriale? Diciamo che dobbiamo sviluppare un programma che invii dei caratteri sulla seriale, caratteri che vorremo ricevere su un normale terminale collegato alla seriale del nostro TINI. Teoricamente tutto quello che dovremo fare è spegnere il server prima di lanciare il nostro programma con il comando stopserver -s. Purtroppo può succedere che senza motivo l intero sistema operativo smetta di funzionare non appena cerchiamo di inviare qualche cosa sulla seriale. Questo problema è dovuto dal fatto che dalla serial0 è presente un PIN chiamato DTR che esegue un reset alla scheda. Alcuni terminali (come ad esempio TeraTerm Pro) quando comunicano con questa seriale vanno a modidifcare lo stato di questo PIN causando un reset involontario. Per evitare questo problema abbiamo la possibilità di disabilitare la funzione di RESET. Per farlo dobbiamo solo togliere il jumper J14 (vedi prossima immagine) sulla scheda. 1 pagina 22 Küng Alan, Dalessi Alan 7 marzo 2004

23 CAPITOLO 5. PROGRAMMARE SU TINI 5.3. Utilizzo della seriale serial0 Figura 5.1: Il jumper J14 7 marzo 2004 Ku ng Alan, Dalessi Alan pagina 23

24 5.3. Utilizzo della seriale serial0 CAPITOLO 5. PROGRAMMARE SU TINI pagina 24 Küng Alan, Dalessi Alan 7 marzo 2004

25 CAPITOLO 6. AGENTE SNMP SU TINI Capitolo 6 Agente SNMP su TINI 6.1 Introduzione Abbiamo trascorso buona parte del nostro progetto a cercare delle librerie o classi SNMP da utilizzare come base per il nostro agente. Sotto riportiamo un elenco di quanto abbiamo trovato nella rete motivando i pro e i contro. Net-SNMP 1 E un progetto sviluppato originalmente dalla Carnegie Mellon University e dalla università della California per la gestione SNMP. Una serie di librerie permette lo sviluppo di agenti e manager SNMP in ambiente C. Nel pacchetto sono compresi molti esempi compilabili su vari sistemi operativi compresi UNIX e Windows. Ha il grosso vantaggio di essere in continuo aggiornamento (ultimo aggiornamento ) e di avere inclusi una grande serie di esempi tra cui un agente e un manager. Supporta SNMP versione 1, 2 e 3. Per contro il pacchetto è composto da molte librerie che a loro volta includono altre librerie. Non risulta facile stabilire quali e quante librerie vengono utilizzate per un determinato programma e questo rende molto difficile il porting verso un sistema embedded. Siamo riusciti a compilare un agente e un manager in ambiente Windows. Purtroppo il gran numero di librerie che vengono incluse ha reso il porting verso TINI difficile a tal punto da indurci a cercare un altra soluzione per l agente. Abbiamo però utilizzato queste librerie come base per il manager su PC. In conclusione possiamo affermare che per lo sviluppo di software SNMP il pacchetto Net-SNMP risulta essere uno dei migliori in circolazione. Netsnmpj 2 E una libreria open source che implementa delle API java utilizzando il codice di base di net-snmp (vedi sopra). Lo sviluppo di un agente con questa libreria richiede anche la presenza della libreria Net-snmp. Abbiamo quindi deciso di escludere questa soluzione per i motivi discussi in precedenza a proposito di Net-snmp. DMH 3 La DMH Software ha sviluppato un agente snmp facilmente portabile su vari sistemi quali Windows, UNIX, Linux, DOS, una serie di Micro-controllers e alcuni sistemi embedded tra cui figura anche il TINI DS80C400. Sul sito troviamo da scaricare gratuitamente il source per vari sistemi operativi ma non troviamo la possibilità di scaricare quello per TINI. Abbiamo più volte cercato di contattare gli sviluppatori marzo 2004 Küng Alan, Dalessi Alan pagina 25

26 6.2. L agente CAPITOLO 6. AGENTE SNMP SU TINI per avere informazioni sulla possibilità di ottenere l agente per TINI ma purtroppo non abbiamo mai ottenuto una risposta. GICL 4 Si tratta di un package open source SNMP per java sviluppato da Jonathan Sevy per il dipartimento di matematica e scienza del computer alla università di Drexel. Permette lo sviluppo di applicativi SNMP come agenti o manager tramite delle semplici classi ben documentate. Purtroppo quasi tutte le classi di questo package sono state sviluppate utilizzando la classe BigInteger (java.math) che la java virtual machine di TINI non è in grado di gestire. Per questo motivo abbiamo deciso di cercare altro. Westhawk 5 Sono una raccolta di classi Java complete e ben documentate ma abbiamo deciso di non utilizzarle perchè sconsigliate da diversi forum per lo sviluppo su sistemi embedded. Sono classi che ben si portano allo sviluppo di software principalmente grafico. jmgmt 6 Si tratta di una serie di classi Java che permettono lo sviluppo di programmi SNMP come agenti o piccoli manager. Le classi sono piuttosto semplici da capire e vengono forniti degli esempi che comprendono un agente. L agente ha dimensioni piuttosto ridotte e non richiede classi particolari se non quelle supportate anche dalla virtual machine di TINI. Dopo aver provato con successo a compilare l agente su TINI abbiamo deciso di utilizzare jmgmt come base per lo sviluppo dell agente definitivo. Lo svantaggio di queste classi è che supportano unicamente SNMP versione L agente Abbiamo sviluppato l agente SNMP per TINI utilizzando le classi Java jmgmt. Principalmente il programma è composto da due thread; la prima, che chiameremo Processo SNMP, permette la ricezione e la gestione di richieste SNMP e la seconda, che chiameremo Processo Combimux, si occupa della comunicazione via seriale con il Combimux. Figura 6.1: Schema generale dell agente sd/mgmt/jmgmt/readme.html pagina 26 Küng Alan, Dalessi Alan 7 marzo 2004

27 CAPITOLO 6. AGENTE SNMP SU TINI 6.2. L agente Il Processo SNMP L agente all avvio utilizza un file di configurazione (vedi capitolo 6.3) per generare in memoria tutti gli oggetti OID a cui un manager potrà fare richiesta di lettura o di settaggio. L agente non gestisce un vero e proprio albero MIB ed è in grado di rispondere unicamente agli OID specificati nel file di configurazione. Un oggetto è definito dai seguenti parametri: OID Contiene il percorso univoco attraverso l albero SMI. Un oggetto viene identificato tramite questo parametro. type Definisce il tipo di valore che l oggetto dovrà contenere. intero) o string (per una stringa.) Può essere int (per un mode Specifica la modalità di accesso a questo oggetto da parte di un manager SNMP. Può essere r(lettura), w(scrittura) o rw(lettura/scrittura). getvalue Contiene il valore che verrà restituito ad una richiesta di get di un manager SNMP. setvalue Quando il manager imposta un valore ad un oggetto che riguarda il Combimux viene salvato in questo parametro. Le differenze tra getvalue e setvalue verranno spiegate più in dettaglio nel capitolo setmode Specifica se questo oggetto conterrà informazioni riguardanti l agente (TA) o il combimux (CM ). Nel caso che riguardi informazioni sul combimux allora l agente utilizzerà uno specifico metodo implementato nell agente stesso. L attributo setmode verrà spiegato più in dettaglio nel capitolo Una volta caricati gli oggetti in memoria l agente sarà in grado di rispondere ad una richiesta di un normale manager SNMP Il Processo Combimux Principalmente esistono due grandi gruppi di oggetti; il gruppo di oggetti che riguardano il manager e quello che riguardano gli stati del Combimux. Esiste una grande differenza tra i due per quanto riguarda la gestione degli oggetti. Questo perchè il valore degli oggetti che riguardano l agente sono prestabiliti mentre il valore degli oggetti riguardanti il Combimux cambiano a dipendenza dello stato del Combimux stesso. Prendiamo ad esempio il caso di un oggetto che contenga lo stato di sincronismo (Freerun o DS2); ci dovrà essere un processo che vada continuamente a controllare quale stato è attivo sul Combimux in quel preciso momento e a scrivere questo valore nel relativo oggetto. Il Processo Combimux ha la funzione di andare continuamente a leggere diversi stati del Combimux e a tenere aggiornati i relativi oggetti. Un suo ulteriore compito è quello di controllare se è stata fatta (da un manager SNMP) una richiesta di modifica ad un oggetto che riguarda il Combimux; in questo caso il processo dovrà inviare una richiesta di modifica al Combimux, richiesta che richiederà un po di tempo per venire processata. Ma come facciamo ad essere sicuri che quando leggiamo un valore questo sia effettivamente lo stato del Combimux? Prendiamo l esempio di prima con l oggetto riguardante il sincronismo. Diciamo che la macchina è in modalità FreeRun; il processo legge lo stato del Combimux 7 marzo 2004 Küng Alan, Dalessi Alan pagina 27

28 6.3. Il file di configurazione CAPITOLO 6. AGENTE SNMP SU TINI e scrive nell oggetto il valore FreeRun. Adesso riceviamo una richiesta di modifica (da un manager SNMP) del valore dell oggetto da FreeRun a DS2. Modifichiamo quindi il valore dell oggetto in DS2. Il processo si accorge del cambiamento e invia una richiesta di modifica dello stato di sincronismo al Combimux. Adesso diciamo che prima che il Combimux riesca a cambiare stato un altro manager chieda lo stato dell oggetto sincro. Incongruenza! Il manager legge il valore DS2 mentre il Combimux è ancora in modalità FreeRun! Ecco spiegato perchè ogni oggetto contiene due campi di valore; getvalue e setvalue. Lo stato effettivo del Combimux è memorizzato nel campo getvalue. Quando riceviamo una richiesta di modifica questa verrà prima memorizzata nel campo setvalue; il processo se ne accorge, invia la richiesta di modifica al Combimux e quando ha cambiato stato il processo va a scrivere il nuovo stato nel campo getvalue Avvio programma compilato Una volta copiato su TINI il programma principale (TINIAgent.tini) e il file di configurazione (objects table.txt) consigliamo di eseguire l applicazione nel seguente modo: java TINIAgent.tini >& log.txt & Così facendo eseguiamo l applicazione in background e ridirigiamo lo standard error (e lo standard output) sul file log.txt che potremmo consultare nel caso si dovessero verificare dei problemi. Se si desidera lanciare automaticamente l agente all avvio di TINI basta scrivere il comando visto sopra nel file /etc/.startup. 6.3 Il file di configurazione Il file di configurazione viene utilizzato dall agente per generare in memoria tutti gli oggetti OID corrispondenti e dal manager per identificare l invio delle richieste all agente. Il file contiene l elenco di tutti gli OID a cui l agente sarà in grado di rispondere. Vediamo come è definito un elemento: OIDpath(type)(mode)(method) OIDpath: Il percorso dell oggetto nel MIB. type: Il tipo dell oggetto, può essere int o string. mode: La modalità dell oggetto, può essere r(lettura), w(scrittura) o rw(lettura e scrittura). method: Specifica se questo oggetto conterrà informazioni riguardanti l agente (TA) o il combimux (CM ). Nel caso che riguardi informazioni sul combimux allora l agente utilizzerà uno specifico metodo implementato nell agente stesso. Ad esempio: (string)(rw)(TA) A questo punto l agente sarà in grado di rispondere ad una richiesta per l OID specificato dal numero che rappresenta l oggetto sysdescr di system. Tutti gli oggetti devono terminare con.0. Visto che rappresentare un oggetto unicamente con il numero pagina 28 Küng Alan, Dalessi Alan 7 marzo 2004

29 CAPITOLO 6. AGENTE SNMP SU TINI 6.3. Il file di configurazione OIDpath può rendere difficoltosa la lettura del file abbiamo la possibilità di aggiungere un commento dopo l OIDpath che assegna all oggetto una stringa. Questa stringa (se presente) verrà anche utilizzata dal manager per assegnare un nome ai vari OID. Vediamo la definizione di un elemento con commento (opzionale ma consigliato): OIDpath(type)(mode)(method) // nome oggetto Ad esempio: (string)(rw)(TA) // sysdescr Tra l OIDpath e il commento ci possono essere degli spazi o dei tabulatori. Un altro parametro opzionale che possiamo aggiungere permette di specificare un valore di default che verrà scritto nel campo getvalue del corrispondente oggetto sull agente. Questo parametro viene indicato con la sequenza di caratteri speciali - subito dopo l OIDpath. Definizione di un elemento con valore di default e commento: OIDpath(type)(mode)(method) -> valore di default //nome oggetto Ad esempio: (string)(rw)(TA) -> Agente SNMP su Tini // sysdescr Per aggiungere più elementi al file di configurazione basta scriverne uno per riga. Vediamo un esempio di file di configurazione: (string)(rw)(TA) -> Agente SNMP su Tini // sysdescr (int)(rw)(TA) -> 123 // sysobjectid (int)(rw)(TA) // sysuptime (string)(rw)(TA) -> SUPSI, Manno // syscontact (string)(rw)(TA) -> TiniAgent (string)(rw)(TA) -> I3B // syslocation (string)(rw)(TA) -> bla bla bla // sysservices Nell esempio visto sopra abbiamo definito tutti gli OID di system. A tutti gli oggetti tranne che sysuptime e sysservices abbiamo specificato un valore di default. Vediamo anche che abbiamo aggiunto il commento per specificare il nome a tutti gli oggetti tranne che per il quinto, quindi quando utilizzeremo il manager per inviare una richiesta potremmo scegliere tra i seguenti oggetti: sysdescr sysobjectid sysuptime syscontact syslocation sysservices Per rendere ancora più chiara la lettura del file di configurazione abbiamo la possibilità di aggiungere righe di commenti in una qualsiasi parte del file. Va anche detto che gli spazi e i tabulatori non vengono presi in considerazione (tranne che per il contenuto delle stringhe) e ne possiamo quindi aggiungerne quanti e dove vogliamo. Vediamo per terminare un esempio completo che comprende tutti gli oggetti di iso.org.dod.internet.mgmt.mib.system e iso.org.dod.internet.private.enterprises.mandozzi.products.seas: 7 marzo 2004 Küng Alan, Dalessi Alan pagina 29

30 6.4. Prestazioni CAPITOLO 6. AGENTE SNMP SU TINI // // MIB file di prova // Versione: // // Data di creazione: // Data ultima modifica: // // Osservazioni: // // // Nodo: iso.org.dod.internet.mgmt.mib-2.system // (string)(rw)(TA) -> Agente SNMP su Tini // sysdescr (int)(rw)(TA) -> 123 // sysobjectid (int)(r)(TA) // sysuptime (string)(rw)(TA) -> SUPSI, Manno // syscontact (string)(rw)(TA) -> TiniAgent // sysname (string)(rw)(TA) -> I3B // syslocation (string)(rw)(TA) -> bla bla bla // sysservices // // // Nodo: iso.org.dod.internet.private.enterprises.mandozzi.products.seas // (string)(rw)(TA) -> aaaa // system sysstatus mode; (string)(rw)(TA) -> bbbb // system sysstatus polling; (string)(rw)(TA) -> cccc // system sysconfig name; (string)(rw)(TA) -> dddd // system sysconfig model; (string)(rw)(TA) // system sysconfig MMnumber; (string)(rw)(TA) // system sysconfig serialnumber; (string(rw)(TA)) -> eeee // system sysconfig firmware name; // Per i commenti si possono usare tutti caratteri tranne che per i caratteri speciali: -, >, /. Precedentemente abbiamo visto che gli oggetti che riguardano il Combimux (setmode = CM) necessitano di un metodo dedicato all interno dell agente stesso e per questo motivo questi oggetti sono tra gli unici a dover essere obbligatoriamente presenti nel file di configurazione. Unica eccezione riguarda l oggetto agente (TA) sysuptime. Questo oggetto deve sempre essere presente nel file di configurazione perchè utilizza un metodo di aggiornamento compilato all interno dell agente. 6.4 Prestazioni La nostra implementazione dell agente SNMP per TINI al momento richiede dei tempi di elaborazione piuttosto lunghi. Ad esempio l inizializzazione del programma, che comprende la generazione degli oggetti in memoria, richiede all incirca 30 secondi. La richiesta di un valore da parte di un manager SNMP richiede circa 1 secondo. Per questo motivo quando si vuole leggere una serie di valori è consigliabile inviare un unico pacchetto con tutte le richieste piuttosto che inviare una richiesta per ogni oggetto. Infatti la richiesta di 6 valori (ad esempio tutti gli OID di System) richiede circa 6 secondi mentre se inviamo la richiesta dei 6 OID con una sola richiesta ci vogliono circa 4 secondi. pagina 30 Küng Alan, Dalessi Alan 7 marzo 2004

31 CAPITOLO 6. AGENTE SNMP SU TINI 6.5. Il manager SNMP Questi tempi sono dovuti principalmente dalla velocità della Java virtual machine di TI- NI, infatti l esecuzione del programma su PC segna dei tempi molto ridotti. Crediamo che questi tempi siano troppo grandi per un applicazione commerciale ma crediamo anche che lavorando sul codice o trovando il modo di migliorare le prestazioni di TINI si possa ridurre notevolmente i tempi d elaborazione. 6.5 Il manager SNMP Introduzione Per testare al meglio il nostro applicativo necessitavamo di un manager SNMP in grado di effettuare le richieste per il COMBIMUX ed interpretare il nostro file di configurazione, che funge da MIB file. Abbiamo deciso di utilizzare Visual Basic 6.0 della Microsoft, in quanto ci è parso il più semplice e intuitivo per sviluppare un interfaccia grafica in grado di adempire le nostre richieste. Per la richiesta di uno o più OID abbiamo utilizzato due programmi contenuti nel pacchetto gratuito Net-SNMP scritti in C. Nelle sezioni e viene mostrata la sintassi da utilizzare per comunicare con l agente Interfaccia grafica in VB 6.0 Figura 6.2: L interfaccia grafica dell SNMP manager. 7 marzo 2004 Küng Alan, Dalessi Alan pagina 31

32 6.5. Il manager SNMP CAPITOLO 6. AGENTE SNMP SU TINI L interfaccia e divisa principalmente in due blocchi: Blocco comunicazione In questo blocco vengono caricati tutti i commenti degli OID nel controllo DropDown (richiesta OID) dal file di configurazione e ognuno di questi elementi e associato ad un OID. Qui di seguito possiamo vedere un esempio di linea del file di configurazione: (string)(rw)(TA) -> Agente SNMP su Tini // sysdescr Una volta aperto il file tramite il menu File - Apri il programma inizia una sequenza di scanning su di esso e memorizza in quattro array diversi l OID, il tipo, la modalità e la descrizione. Per quanto riguarda il campo che indica l appartenenza dell oggetto, in questo caso Tini Agent (TA), e quello del valore preimpostato (Agente SNMP su Tini) il programma non ne tiene conto perché sono campi interessati esclusivamente dall agente. Grazie a questi quattro array possiamo controllare ogni singolo campo riferendoci esclusivamente all indice di essi, in poche parole se vogliamo inviare una richiesta di sysdescr, selezionata dal controllo DropDown, il programma memorizza l indice e invia il dato contenuto nell array degli OID a quella posizione senza processare l intera riga ogni volta. Ad ogni cambiamento del DropDown viene lanciato una evento che controlla il tipo e la modalità dell oggetto affiggendoli sull interfaccia; nel caso della modalità vengono pure controllate le tre diverse possibilità (R,W,R/W) e in base ad esse l interfaccia permette di effettuare solo richieste,solo letture oppure entrambe. In questo blocco si può definire pure l IP dell Agente con cui comunicare, grazie all oggetto di testo formattato per contenere solo IP validi; cioè con valori, per ogni campo, che vanno dallo 0 al 255. Blocco Status Combimux In questo blocco sono rappresentati i controlli principali per il comando del combimux. Gli otto led rappresentano esattamente quelli sul frontalino dell apparecchio, in questo modo premendo sul pulsante aggiorna si manda una richiesta di stato all OID che ritorna tredici byte di coi uno, precisamente l ottavo, contiene lo stato dei led; ad ogni bit corrisponde lo stato di ogni singolo led. (1= acceso e 0 = spento) All avvio del programma tutti questi controllo sono nascosti, e presente un unico pulsante che impone una lettura dello stato iniziale dell apparecchio. Il pulsante di Reset invia il corrispondente comando al combimux, una volta identificato il comando gli otto led vengono accesi e poi ritornano allo stato precedente; in questo modo, specialmente durante le prime prove di comunicazione, avevamo un riscontro visivo del funzionamento. L ultimo controllo permette la scelta del modo di sincronismo, FREERUN o DS2, anche qui la conferma la si può verificare tramite i led appositi Net-SNMP snmpget Quest applicazione permette di richiedere uno o più OID all agente. Sintassi : snmpget [OPZIONI] AGENTE OID [OID]... pagina 32 Küng Alan, Dalessi Alan 7 marzo 2004

33 CAPITOLO 6. AGENTE SNMP SU TINI 6.5. Il manager SNMP OPZIONI: -h, help visualizza l help -v 1,2c,3 specifica la versione SNMP da utilizzare -V, version visualizza il numero di versione del package Opzioni specifiche per SNMP versione 1 o 2c -c COMMUNITY imposta il nome della comunità Opzioni generali di comunicazione -r RETRIES imposta il numero di tentativi -t TIMEOUT imposta il timeout (in secondi) esempio di richiesta singola: snmpget -v 1 -c public risposta : iso = STRING: Agente SNMP su TINI esempio di richiesta multipla: snmpget -v 1 -c public risposta : iso = STRING: Agente SNMP su TINI iso = STRING: 123 Nel caso di richieste multiple i dati ritornano separati da un carattere di ritorno a capo e quindi facilmente interpretabili Net-SNMP snmpset Quest applicazione permette di settare una o più variabili nell agente,ma nel nostro caso ne settimo sempre una alla volta. Sintassi : snmpset [OPTIONS] AGENT OID TYPE VALUE [OID TYPE VALUE]... OPZIONI: -h, help visualizza l help -v 1,2c,3 specifica la versione SNMP da utilizzare -V, version display package version number SNMP Version 1 or 2c specific -c COMMUNITY imposta il nome della comunità General communication options -r RETRIES imposta il numero di tentativi -t TIMEOUT imposta il timeout (in secondi) esempio di set: snmpget -v 1 -c public risposta : iso = STRING: Agente SNMP su TINI 7 marzo 2004 Küng Alan, Dalessi Alan pagina 33

34 6.5. Il manager SNMP CAPITOLO 6. AGENTE SNMP SU TINI Istruzioni in breve All avvio dell interfaccia viene caricato automaticamente un file (boot.txt) contenente le richieste principali dell oggetto System; inoltre, tramite il menu File -> Apri..., c e la possibilità di caricare un qualsiasi file di testo nel formato corretto. Figura 6.3: Menu file-> apri È molto importante che il file caricato nel manager corrisponda o abbia almeno una parte degli oggetti contenuti nel file dell agente su TINI, altrimenti le risposte risulterebbero tutte vuote. A dipendenza dei modi di accesso assegnati agli OID sono disponibili i controlli get e set. Figura 6.4: Controlli set e get nel caso di un tipo R/W Prima di effettuare una qualsiasi richiesta e importante inserire l IP corretto nell apposito controllo, per evitare messaggi di timeout. Figura 6.5: Controllo IP Le risposte da parte dell agente verranno visualizzate nel seguente controllo. Figura 6.6: Controllo risposta Dall immagine si può notare che la risposta è composta dall OID, dal tipo di dato e dal dato richiesto o appena impostato. Sono presenti, inoltre, dei controlli visivi che mostrano lo stato del COMBIMUX in qualsiasi momento a discrezione dell utente. Premendo il pulsante Visualizza Status si visualizzano i controlli aggiornati in quel istante.l operazione pagina 34 Küng Alan, Dalessi Alan 7 marzo 2004

35 CAPITOLO 6. AGENTE SNMP SU TINI 6.5. Il manager SNMP può richiedere alcuni secondi perche vengono richieste diverse informazioni. Figura 6.7: Attivazione della richiesta di status Una volta attivata la nuova parte dell interfaccia, tramite il pulsante aggiorna e possibile aggiornare i controlli. L IP di riferimento e sempre quello inserito nel controllo precedente. Figura 6.8: Controlli status COMBIMUX 7 marzo 2004 Küng Alan, Dalessi Alan pagina 35