Team Members:
Gaurav Kataria
Mike Cho
Omer Ansari
Vishal Bhargava

Summary of Project:
The project goal is to learn the functionality and implementation of SNMP (Simple Network Management Protocol) which is one of the several well known Internet protocols used in the Industry.
What we intend to learn is how the protocol works internally from the server (snmp agent) point of view
(a) by designing the framework of standard snmpv1 type operations.
(b) and by writing code to entertain several network oriented queries
We intend to use C/C++ and Perl in our project, and hope to also learn the various facets of programming which deal with socket programming and network oriented data structures.
 

Description of Project:

Essentially, the game plan it to write an snmp daemon which would run on a linux machine. C/C++ and/or Perl would be used to develop this daemon.
This daemon would listen on udp port 161 for snmp get/set queries and would entertain snmpv1 type queries.
 

It would be able to entertain snmp requests from any RFC 1157 compliant snmp client. (an snmp client would also be developed during the course of this project, which is documented in the end)

Their are two major aspects of what we intend to learn here:
1. understanding the basic framework of an snmp daemon:
how it accepts a udp packet, extracts the payload as per snmp PDU definitions, interprets the request made, carry out actions as per request, compose an snmp pdu with a response, encapsulate it in snmp, and send it back to the requesting party.

if it is a read only requests make system calls to acquire the information. if it is a read-write request, the make system calls to carry out the request, and display the results of the outcome as per the definition in the respective RFC.

2. how to entertain the requests made:
essentially, what type of functions to write (system calls etc to make) to entertain the requests being made.

Both read-only (snmpget, snmpgetnext) and read-write (snmpset) requests would be entertained.

However, the above requests would be within the realm of defined RFCs. (In other words the snmp daemon would abide to parts of known RFC MIBs) Any get/set requests made outside the scope of defined data structures of the RFC MIBs would not be entertained as the goal for us is not to invent new MIBs but to write code to support documented MIBs.
 

Owing to time constraint, complete RFCs would not be implemented. Instead, only those parts would be committed to which are more network oriented.

This decision has been made keeping in mind the thrust of this course.

The parts / trees of the RFCs that we plan to implement are are from the RFC 1213 well documented inside it:
http://rfc.sunsite.dk/rfc/rfc1213.html

The System Group:
=======
+--system(1) detail
|
+-- -R-- String sysDescr(1)
| Textual Convention: DisplayString
| Size: 0..255
+-- -R-- ObjID sysObjectID(2)
+-- -R-- Timeticks sysUpTime(3) detail
| |
| +--sysUpTimeInstance(0)
|
+-- -RW- String sysContact(4)
| Textual Convention: DisplayString
| Size: 0..255
+-- -RW- String sysName(5)
| Textual Convention: DisplayString
| Size: 0..255
+-- -RW- String sysLocation(6)
| Textual Convention: DisplayString
| Size: 0..255
+-- -R-- Integer sysServices(7)
| Range: 0..127
 

The System group should be the most easy to implement. This has both readonly and readwrite options, which should enable us to test our framework originally.

The IP group:
============
+--ipNetToMediaTable(22) detail
| |
| +--ipNetToMediaEntry(1) detail
| | |
| | +-- -RW- Integer ipNetToMediaIfIndex(1)
| | +-- -RW- String ipNetToMediaPhysAddress(2)
| | | Textual Convention: PhysAddress
| | +-- -RW- IpAddr ipNetToMediaNetAddress(3)
| | +-- -RW- EnumVal ipNetToMediaType(4)
| | | Values: other(1), invalid(2), dynamic(3), static(4)
 

We focus mainly on the ipNetMediaTable (the arp table) in the IP group. This would enable us to show the current arp cache on the system, and also invalidating arp entries too (as you can see the RW flags)

The ICMP group:
================
+--icmp(5) detail
|
+-- -R-- Counter icmpInEchos(8)
+-- -R-- Counter icmpInEchoReps(9)
+-- -R-- Counter icmpOutEchos(21)
+-- -R-- Counter icmpOutEchoReps(22)

We would only show the icmp in and out echo requests and replies. This is to show how the counters would increment during a demonstration.
 

The TCP group:
====
+--tcpConnTable(13) detail
| |
| +--tcpConnEntry(1) detail
| | |
| | +-- -RW- EnumVal tcpConnState(1)
| | | Values: closed(1), listen(2), ... deleteTCB(12)
| | +-- -R-- IpAddr tcpConnLocalAddress(2)
| | +-- -R-- Integer tcpConnLocalPort(3)
| | | Range: 0..65535
| | +-- -R-- IpAddr tcpConnRemAddress(4)
| | +-- -R-- Integer tcpConnRemPort(5)
| | | Range: 0..65535
 

This table would show what types of tcp connections exist on the box, and also give us an option of resetting a certain connection by using a set on the tcpConnState
 
 

We are not committing to sending traps from this snmp agent, the idea being that we want to focus on a client/server model for this project, and traps really don't fit into a response/request mechanism due to their asynchronous nature.
 

Snmp Client

A corresponding snmp client would also be written. This may be implemented in perl entirely. This client would essentially be a suite of different snmpv1 operations:

snmpget
snmpset
snmpgetnext
snmpwalk (essentially a wrapper around snmpgetnext)

these are documented in RFC1157:
http://rfc.sunsite.dk/rfc/rfc1157.html