OpenBSD Journal

The value of testing, how you can help OpenBSD

Contributed by jl on from the if-it-is-broke-do-try-to-fix-it dept.

Recently Reyk Floeter (reyk@) checked in snmpd(8) which was mentioned earlier. Will Backman writes in with his experience testing it:
I wish I had mad coding skillz, but I have found that even non-developers have something to contribute in the form of equipment and time. When a call for testing goes out, my desire to tinker pushes me to install a snapshot and play with some of the new software that I'd like to use in the next release. Testing software not only helps me become more familiar with the new features, but can also help flush out bugs or documentation errors. I was excited when I saw that Reyk Floeter (reyk@) had commited a new snmp daemon to the tree, and I knew it was something that I would like to use as soon as possible. Like a mad scientist, I dragged out one of my frankenstein machines and proceeded to experiment on snmpd.
The first test was to query the daemon with the traditional net-snmp tools such as snmpwalk and snmpset. Everything was clearly explained in the man pages and the default /etc/snmpd.conf (5)worked as expected. It is important to change the write community before you set snmpd to listen to the network, and you may even want to use pf(4) to limit your exposure to random hosts. I don't do anything particularly complicated with snmp, and the commercial PRTG software that I use was happy to connect and read interface statistics from the test machine. Now it was time for some unusual tests.

To simulate running over a long period it time, I set up a simple loop with snmpwalk.
while true; do snmwalk -c public 10.1.100.97 system ; done
After a while, it became apparent that there was a memory leak. Running the top(1) command showed that the snmp daemon was using over 200MB of RAM and growing. It was time to fetch the latest source from CVS and see if the problem still existed in the latest version. Unfortunately, the leak was still there. From what I have read, this is an easy mistake to make and a difficult one to find. I have a hard enough time writing a "hello world" program in C, so I was in no position to track down an obscure bug in unfamiliar code. It was time to file a bug report with as much information that I had. I was pleasantly surprised when I heard back from the developer in less than a day. He was able to confirm the leak on his system, and suggested some further test that I could run to help narrow down the problem until he had more time to take a serious look at it. Following Reyk's suggestions, I ran loops of snmpwalk, snmpbulkwalk, snmpget, and snmpset against different types of objects in the MIB, such as Integer, String, and Timeticks. Apparently there are different handlers for different types of objects, and if we were lucky, the leak could be narrowed down to a small part of the code if the problem only happened when querying one type of object. Alas, it was not the case, but I hoped that my testing would at least save some valuable time.

By the next day, a fix had been committed, and I received a nice note of thanks from Reyk. This has been my typical experience when interacting with developers, and I'm always amazed at how accessible and responsive they are when I contact them with a useful bug report and a willingness to help resolve the problem. I'm not a programmer, but it is still exciting to participate in the process. I encourage everyone to contribute what they can, whether it be money, time, equipment, or documentation. So when a call for testing goes out, please do. It benefits the developers, the community, and eventually you.

(Comments are closed)


Comments
  1. By Anonymous Coward (24.37.242.64) on

    Minor error in the linked URL from the man page, via openbsd.org:

    http://www.openbsd.org/cgi-bin/man.cgi?query=snmpd&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

    Has the comma linked too.

  2. By Anonymous Coward (85.195.123.22) on

    I found a bug in 4.1 release. Read Dailychangelog of 4.1-4.2, 4.2-current. Nothing addresses. Haven't read the CVS changelogs.
    This bug might be a good one to keep secret and in OS though. Helpful. Displays interesting behavior, that could be considered boorish and rude! Not remote, local only, process limits should restrict it, but...this shouldn't happen!
    Haven't validated this in other configs. Stock Generic kernel.
    Perhaps more later...this is why testing is important. Can't assume anything.

    I don't mean to annoy you, just that I find this hard to believe this not on purpose? So keeping it secret for now.
    Why do I keep repeating myself recursively almost, without being helpful? GRR. Sure stuck on this one... This one breaks all limits that are reasonable, sure weird....

    :)

    Comments
    1. By chris cappuccio (198.175.14.193) on


      > I don't mean to annoy you, just that I find this hard to believe this not on purpose? So keeping it secret for now.

      You're right. You're a fucking genius. You've found the hole that allows developers to secretly log into your machine and use more processes than you've allocated for them!!! Stop the presses!!! We've got a new front page article!c

      Comments
      1. By Anonymous Coward (85.195.119.14) on

        Poster of 'issue' here. While I did expect such a response; drama is fine with me; my main point is that TESTING is a critical part. It might be easy to assume that OpenBSD is perfect on some BASE levels. OpenBSD is great, it amazes me the attention to detail, I just was shocked when some undesired unexpected operations went down. Seemed to fit the Undeadly posting of testing, and unexpected things that can happen.

        Your response is tongue in cheek, ok, but to clarify, not remote, not security, just an unexpected PITA DOS. This is not the '$ file_name >> file_name' newbie DenialOfService. Hopefully I can figure this out and follow proper OpenBSD bug reporting procedure.

        Cheers.

        Comments
        1. By Anonymous Coward (198.175.14.5) on

          > Your response is tongue in cheek, ok, but to clarify, not remote, not security, just an unexpected PITA DOS. This is not the '$ file_name >> file_name' newbie DenialOfService. Hopefully I can figure this out and follow proper OpenBSD bug reporting procedure.
          >
          > Cheers.


          Well, so why not file a bug report? Instead of posting this, file a bug report. Do the world a favor.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]