Low Level DPI Funktionen

Der grundsätzliche Ablauf der DPI Kommuniktion wurde bereits im vorigen Kapitel abgehandelt. An dieser Stelle soll nur gezeigt werden, welche Funktionen der Subagent zur DPI Kommunikation zur Verfügung stellt.

• qDPIport()
  qDPIPort() ermittelt über eine SNMP Verbindung unter UDP zum Hauptagenten den Port, auf dem der Agent bereit ist, eine DPI Verbindung aufzubauen. Die Funktion benötigt den Hostnamen des Rechners, auf dem der Hauptagent läuft in der globalen Variable $AGENT_HOST.
• TCPConnect()
  TCPConnect() baut auf dem übermittelten Port eine TCP Verbindung zum Rechner, der in der globalen Variable $AGENT_HOST genannt ist, auf. Nachdem die Funktion erfolgreich beendet wurde, existiert ein PERL Filehandle namens DPI_Anschluss für die weitere Kommunikation.
• DPI_Open()
  Diese Funktion dient dazu, eine Verbindung mit dem DPI fähigen SNMP Hauptagente aufzubauen. Sie erstellt ein DPI-Open-Request Paket und verschickt dieses an das Filehandle DPI_Anschluss. Wird das Anfragepaket durch ein Responsepaket vom Hauptagenten positiv beantwortet, so wird hinter den Aufruf der Funktion zurückgekehrt. Andernfalls wird das gesamte Skript mit einer Fehlermeldung beendet.
• DPI_Register()
  Diese Funktion registriert den Teilbaum der MIB, für den der Subagent zuständig ist, beim Hauptagenten. Dazu wird dem Hauptagenten in einem DPI-Register-Request Paket die Wurzel des Teilbaums übermittelt. Diese Funktion erwartet die Wurzel in der globalen Variable $GROUPID. Wird die Registrierung durch ein Responsepaket vom Agenten positiv beantwortet, so wird hinter den Aufruf der Funktion zurückgekehrt, andernfalls wird das Programm beendet.
• DPI_Unregister()
  Meldet den zuvor registrierten Teilbaum wieder beim Agenten ab. Auch diese Funktion erwartet die Wurzel des Teilbaums in der globalen Variablen $GROUPID. Die Funktion wartet auf eine positive Antwort vom Hauptagenten und wird dann normal beendet. Tritt ein Fehler auf, oder weigert sich der Agent, die Abmeldung anzunehmen, wird ein DPI_Close() verschickt und das Programm beendet.
• DPI_Close()
  Diese Funktion meldet den Sub- beim Hauptagenten ab. Die Funktion erwartet keine Parameter und hat keinen Rückgabewert.

Dieser Funktionsblock darf bei der Implementierung als Black Box betrachet werden. Er wird nur einmal im Modul subagent_standard.pl abgearbeitet:

# Ermitteln des TCP-Port's, der fuer die DPI-Kommunikation
# mit dem Agenten benutzt werden soll.
$Port = &qDPIport;
print "Port:$Port\n";

# Ueber den ermittelten Port eine TCP-Verbindung zum Agenten
# aufbauen (fuer die DPI-Kommunikation) => Handle: DPI_Anschluss
&TCPConnect($Port);

# Oeffnen der DPI-Verbindung
&DPI_Open;
sleep 1;

# Registrieren des Teilbaums
&DPI_Register;

...

# Unregistrieren des Teilbaums
&DPI_UnRegister;

# Schliessen der DPI-Verbindung
&DPI_Close;

# Schliessen des Handles fuer die TCP-Verbindung zum Agenten
close(DPI_Anschluss);
}
########################################################
# Ende des Hauptprogramms
########################################################

Interessanter sind die beiden folgenden Funktionen, die z.B. beim Implementieren eigener, von den generischen Funktionen abweichenden, GET und SET Funktionen benötigt werden:

• ResponseError()
  ResponseError verschickt ein Fehlerpaket an den Hauptagenten. Die Funktion erwartet dabei als Parameter die Paket-ID des Pakets, welches den Fehler verursachte und einen Fehlercode nach Tabelle 18 im RFC 1592.
• ResponseSuccess()
  Hat der Hauptagent den Wert einer Variablen angefordert, wo wird dieser mittels ResponseSuccess() an den Agenten gesendet. Dabei erwartet die Funktion folgende Parameter:
  • Paket-ID. Dies ist die ID des Anfragepakets, welches beantwortet werden soll.
  • Group-ID. Die ID der Gruppe, in der sich die Variable befindet.
  • Instanz-ID. Die ID der Instanz, also die Bezeichnung, welche die Variable in dem vom Subagent verwalteten Teilbaum besitzt. Hängt man die Instanz-ID an die Gruppen-ID, so erhält man die komplette Object ID in der MIB.
  • Wert der Variable. Hier wird der Wert der Variable in der jeweiligen Darstellung übergeben. Wird in einer Reihe von GETNEXT Requests das Ende der MIB erreicht, so ist der Funktion ResponseSuccess() der Wert ENDofMIB zu übergeben.
  • Typ der Variable. Typ der Variable (Nummerncode aus Tabelle 17 in RFC 1592, aber Hex).

Hinweise für die eigene Implementierung:

Es ist wichtig zu beachten, daß das Beantworten von Fehlern z.B. beim GET Zugriff auf nicht vorhandene MIB Variablen mittels ResponseError() SNMPv1 Verhalten ist und nach Möglichkeit nicht genutzt werden sollte.
Unter SNMPv2 wird stattdessen ein detaillierter Fehlercode als eigener Typ zurückgeschickt. Die generischen GET und SET Funktionen dieses Subagenten reagieren unterschiedlich, je nachdem, wie die globale Steuervariable snmpversion gesetzt ist:

    ...
    $Wert = &get($InstID);
    if (defined ($Wert)) {
        &ResponseSuccess($dpi_get_packet_id,$GID,$InstID,$Wert);
    }
    else {  # Nicht vorhanden
        if ($$snmpversion == 1) {
            # SNMP_ERROR_noSuchName
            &ResponseError($dpi_get_packet_id,"02")
        }
        else {
            # SNMP_TYPE_noSuchInstance
            &ResponseSuccess($dpi_get_packet_id,$GID,$InstID,$Wert,"10");
        }
    }
    ...

Dieses Verhalten sollte auch beim Implementieren eigener GET und SET Funktionen, die Gebrauch von ResponseError() oder ResponseSuccess() machen, modelliert werden.

Weiterhin ist zu beachten, daß nur die folgenden SNMP Typen für ein ResponseSuccess() implementiert sind:

• SNMP_TYPE_OCTET_STRING
• SNMP_TYPE_OBJECT_IDENTIFIER
• SNMP_TYPE_endOfMibView
• SNMP_TYPE_Integer32
• SNMP_TYPE_noSuchObject
• SNMP_TYPE_noSuchInstance

Die Funktion ResponseSuccess() läßt sich aber leicht um weitere Typen erweitern, wenn man die if-then Schleife entsprechend erweitert. Die Konstruktion eines entsprechenden Packstrings, also die Kodierung des neuen Typen findet man im RFC 1592.