Project of the Month, March 2005

net-snmp provides tools and libraries relating to the Simple Network Management Protocol including: An extensible agent, An SNMP library, tools to request or set information from SNMP agents, tools to generate and handle SNMP traps, etc.

Project Name: Net-SNMP (formerly UCD-SNMP)
Founded / Started: June 1995

URL: http://www.net-snmp.org/
Project page: https://sourceforge.net/projects/net-snmp/

Description of project:

Net-SNMP implements the Internet standard mechanism for network management, including the most recent SNMPv3. It allows system and network managers to monitor and manage hosts and network devices.

Trove info:

• Development Status: 6 – Mature
• Intended Audience: Developers, System Administrators
• OS: Linux, Solaris, HP-UX, Windows, FreeBSD, NetBSD, QNX, all 32-bit Windows (95/98/NT/2000/XP), all POSIX (Linux/BSD/UNIX-like OSes).
• Language: C, Perl
• Topic: Internet, monitoring
• Translations: English
• User Interface: X Window System (X11), command-line, non-interactive (daemon)
• License: BSD

Why and how did you get started?

Wes: In 1994 or 1995 I was working for the University of California at Davis and needed to manage a large number of Unix machines (~200) that exhibited particular recurring problems (servers crashing, disk space filling up, services failing to respond, memory running out, and so on). I took the then-unsupported CMU-SNMP package and modified it to work on HP-UX and later Ultrix, SunOS, and others. I originally distributed the work as a patch to the CMU-SNMP package. It was very well-received. I decided it should become its own package. It started as a mailing list and FTP site and now makes use of most of the SourceForge services.

Dave: I wanted to detect printing problems before they got out of hand, and decided that I needed to replace the vendor-supplied SNMP agent. I started tweaking the UCD agent, and feeding the changes back to Wes, and sort of got sucked in from there. That was over nine years ago, and I still haven’t got back to the printing problem!

Niels: I received responsibility for a server room at a PPOE in 1995 and startedlooking around for tools. SNMP looked good on paper, but the availableagents were few and lacking, especially from OS vendors. My main servers were Solaris-based, so I started hacking the Solaris support in UCD-SNMP. At that time Dave was hacking the HP-UX parts, and Wes mostly Linux and (Free)BSD.

Robert: I got started with the precursor to Net-SNMP, UCD-SNMP, when the IETF was (unsuccessfully) trying to define SNMP v2 to add security to SNMP. My employer didn’t want to wait for the IETF, so I had to add the proposed access control stuff to an existing v1 agent. As I settled into the niche market of doing agent development, I used UCD-SNMP and Net-SNMP again and again, occasionally fixing bugs I found or submitting new features that my clients needed.

Mike: In 1998 I joined Internet Security Systems’ X-Force and began investigatingdifferent approaches to scanning for SNMP vulnerabilities across large IP address ranges. At the time, a colleague recommended that I investigate UCD-SNMP. I discovered that with careful preparation of the MIB file loading prior to opening any SNMP connection, a parallel set of function calls could be used to invoke the SNMP functionality in a *mostly* thread-safe manner without requiring resource locks. This became the single session API that has been part of Net-SNMPsince UCD-SNMP 3.5. After joining Trusted Network Technologies, I did not participate in Net-SNMP development until December 2003, when it became necessary to update the SNMP library and agent builds to work on Win32 platforms. I met Alex Burger and Andy Smith, and we teamed to create the installable Windows packaging of Net-SNMP 5.1.2.

What is the software’s intended audience?

Anyone involved with network management — network administrators, operators, and developers, including those developing their own agents for MIBs that are not included with Net-SNMP (e.g. proprietary devices). Some operating system vendors bundle it with their software, and various hardware manufacturers embed it within their networking devices. Net-SNMP has tried to maintain a fine line between offering new technologies for experimenters, educators, and students, and a robust working product for system and network administrators.

How many people do you believe are using your software?

We don’t know. It’s likely to be used by multiple people at any given organization. Additionally, it’s distributed by Red Hat, Debian, Solaris, Apple, YellowDog, FreeBSD-ports, and available on various package repositories (such as HP-UX packages). I think from the SourceForge site we’ve hit about 43,000 downloads for a single version.

What are a couple of notable examples of how people are using yoursoftware?

I’ve heard from people that use it in a wide variety of ways, including managing ground-based radar stations, computers in at airport terminals, military devices, and taxi networks.

What gave you an indication that your project was becoming successful?

The volume of email traffic on the mailing lists! We average about 400 a month at least on the users mailing list, and 300 or so on the development list. Another significant indication was when Red Hat Linux adopted ucd-snmp instead of the cmu-snmp-linux package in mid-1998. The most recent major event was when Solaris 10 shipped with Net-SNMP’s agent and software instead of their previous Sun-specific SNMP software.

What has been your biggest surprise?

Wes: The friends that I’ve made through the process. The most outstanding thing about open source development I think is the interaction you get with people from all over the world. It’s not only beneficial to the project, but to each individual that contributes as well. It surprised me to have people come up to me at conventions and ask me if I was the one who had started the project and tell me they used it loved it and used it extensively. I never expected to be discovered in a crowd because of my name tag merely because I started a project to help people make use of an obscure management protocol.

Dave: My biggest single surprise was being asked to write an article about the project in the Simple Times (Vol 10, #1). More generally, I’m continually surprised at how many independent projects rely on our code, and how highly we figure in the SourceForge rankings. We’ve consistently been in the top 1% (almost three-quarters of our time here overall, and solidly for the last year plus) and have only dropped out of the top 10% once in over four years. Not bad for what is a somewhat specialised package!

What has been your biggest challenge?

Wes: The high portability of the package poses the biggest challenge. In order to keep every part of the software supported, we need developers who have knowledge about the internals of many different system types. As people come and go from a project, it’s hard to keep a good spread of those who can answer questions about hardware that the core developers don’t have available. The SourceForge compile farm has certainly helped this endeavor, but Net-SNMP’s daemons frequently need root-level access for device access, and the variety of hardware Net-SNMP has code for is much larger than exists in any one place. A diverse developer set is a necessity for the project to continue to support as many platforms as possible.

Dave: Responding to the growth in usage of the software — in particular the number of queries on the mailing lists. Providing a useful level of support can be a significant workload.

Niels: We are constantly trying to keep up with new OS versions that keepchanging the interfaces to the data we need.

Robert: Trying to balance work, a real life, and contributing to an open source project.

Why do you think your project has been so well-received?

Wes: We try really hard to figure out what is missing from the project based on current mail to the lists, and to see if we can support that in future releases. My early policy on what to work on next was to work on something that would help reduce the most frequently asked question on the list. The result was, unfortunately, not fewer questions but rather more difficult questions, but I’m still an avid proponent of that technique.

Dave: Our software is surprisingly portable (considering that it “just growed”) and runs on a wide variety of systems. It’s also fairly broad (providing both an SNMP development toolkit and a range of client applications as well as the extensible SNMP agent), and the agent itself provides a useful amount of information out of the box.

Niels: It both implements a large set of MIBs in itself, and at the same timeis extensible both by scripting and by adding code.

Robert: It’s free, it works, and it is distributed under a BSD license. The BSD licence is a big deal, since companies that are leery of the GPL use our code in their devices.

Mike: The core developers are responsive and helpful to newcomers and experiencedusers. I think their quality rivals many companies who charge for support.

Where do you see your project going?

Wes: SNMP is a useful protocol, but it’s hard to use sometimes, not because of the complexity of the software or the protocol, but because of the complexity of the data it’s trying to manage. I’d like to see Net-SNMP do a better job trying to reduce that complexity wherever possibly by adding more powerful aggregation tools.

Dave: The main thrust recently has been in improving the APIs, particularly with the aim of making it easier to develop new MIBs. This is likely to continue. I also expect to see an increase in the range of systems that it runs on, and improvements in the support for existing architectures (particularly on Windows systems).

What’s on your project wish list?

Wes: The current trend in network management is distributed management. When networks scale to really large sizes, central management becomes a burden. It would be nice to see Net-SNMP branch into areas to fix this problem.

Dave: Re-structuring the library code. The v5 release saw significant improvements to the organisation of the agent, making it much more modular and flexible. The library code hasn’t really changed that much from the original CMU suite, and is long overdue a comprehensive review. I’d also like to continue revising and updating the UCD-specific MIBs, to address some of the design problems that have come to light over the last 10 years. This could also involve closer links with the Host Resources MIB implementation, perhaps using some form of hardware abstraction layer.

Robert: Multi-threading. I don’t think we’ll get to it any time soon, though.

What are you most proud of?

Wes: The high quality of developers that the project has attracted.

Dave: Probably the AgentX implementation. Several people have worked on this since I first wrote the code, and it’s now much more solid and reliable. But the basic design has proved sound, meaning that the MIB developer doesn’t need to worry about how the MIB will be included in the agent.

If you could change something about the project, what would it be?

Wes: I’d like to rewrite the entire configure script. I think we must hold a record for the largest configure script ever written, and it shows. Fortunately, changing it is a realistic goal, but a hard one. The functionality is all still needed, but the tangled web that encloses it could be drastically simplified.

Dave: The code structure — especially that of the library. Both the file organisation and the data structures are far from ideal. Unfortunately, we’ve always felt constrained by the need to keep backwards compatibility with existing code, which limits how much we can change.

Robert: I’d like to do a complete re-write. This code has been around for a long time, and had lots of different people tacking on bits and pieces here and there.That makes for a bit of a mess.

Mike: I would like more online collaboration through a wiki mechanism. We use email extensively, and it is difficult to grow ideas that way.

How do you coordinate the project?

Coordinate the project? What a good idea – we should try that sometime!

But seriously, much of the coding tends to be done independently, by people working on a specific area of functionality. We rely on email to keep each other informed about what we’re doing. The aim is to discourage developers from going quiet for an extended period, and then suddenly coming out with a whole new subsystem. Commit little and often is the rule. We have a mandate that all development and design decisions be vetted on our development mailing list.

Do you work on the project full-time, or do you have another job?

Part-time.

If you work on the project part-time, how much time would you say you spend, per week, on it?

Wes: It varies widely, from 10 to 50 hours. A lot of the time, I’m not always working on things that directly affect Net-SNMP immediately but do affect its future. For example, I’m currently sitting in a meeting at the IETF about the future of SNMP security.

Dave: Until recently, probably an hour or two a day answering queries on the mailing lists, plus whatever time I can find for coding or documentation. That could easily come to something like 30 hours a week.

Niels: All that I have now to give the projects is 1 to 2 hours a week.

Robert: 10 to 20 hours.

Mike: As many as it takes to propose, foster agreement, implement, test, and check-in. That usually runs less than 20 hours a week when I’m fired up.

What is your development environment like?

Wes: I develop almost entirely on Linux on a x86 laptop these days with the gcc compiler. I do all of my debugging directly in gdb (sometimes within XEmacs) and/or the Perl debugger.

Dave: Predominately Linux – some HP-UX, and occasional dabbling in Windows. I’m a Luddite at heart, so tend to use the old-fashioned approach (vi/gcc/gdb cycle) rather than a full IDE. A lot of both documentation and coding gets done on my laptop in text mode during the train journey to and from work.

Niels: x86, SPARC and VMware; Solaris 8, Solaris 9, Linux, FreeBSD 4 and 5,NetBSD 1.6 and 2; gcc; gdb; dmalloc.

Robert: YellowDog Linux on Apple PowerBooks, for primary development. Mac OS X (via MacOnLinux) for testing. Fedora Core on a generic AMD machine, as primary server and for testing. I use Xemacs to code and compile, and DDD for debugging.

Milestones:

• June 1995 v3 release (as UCD-SNMP) – first public spin-off from the original CMU code
• Sept 1998 multi-developer CVS access, marking the start of being a proper open source project
• Aug 1999 v4 release – introduced SNMPv3 and AgentX support
• Dec 2000 move to SourceForge (and change of project name)
• Apr 2002 v5 release (as Net-SNMP) – new more modular architecture
• Nov 2004 v5.2 release
• Jan 2005 v5.2.1 release – latest stable line

How can others contribute?

Wes: The best way is to participate on the mailing lists. As we frequentlysay, “patches welcome.” That being said, in the same way that we encourage the primary developers to discuss new features on the mailing list first, we’d hope that other developers of new patches would follow suit. Patches can be submitted via the “Patches” tracker system, or posted to one of the mailing lists.

Dave: One area that is sadly lacking is good documentation — how to configure and run the agent; how to use the existing tools; how to develop new ones; how to design and implement new MIBs; etc.

Another useful contribution would be assistance with “unusual” operating systems that the core developers don’t have access to. It would be useful to have feedback as to whether things work properly on other architectures, particularly during the pre-release cycle. Suggested fixes would be ideal, but even just reports of a problem can prove very helpful.

There’s a wishlist of various projects on the Net-SNMP Web pages at http://www.net-snmp.org/dev/projects.html

Niels: Our main problem is keeping up with evolving operating systems. Ourprime development systems are various Linux systems. Some OSes have portsand packaging of Net-SNMP, and it really would be a help if these porterscommunicated back to us with their patches.

Robert: The two areas that could use the most help are support on the mailinglists and documentation.

Mike: Those who have time to run a software metrics analysis (how frequently function b is used, and its call distribution across the base) are welcome to do so. Testing is one area that the project could use work in. The “make test” scripting helps develop confidence, and other “unit test” types of verification would go a long way in identifying regression points.