At the very end of the development stage I discovered a bug in the
SNMP set code for scotty. It's not a major one and you can get around
it without the modification most of the time.


# set up the session and show that the public commnity does not accept sets
[~/code/scotty]$scotty
% snmp session -address frank
snmp0
% snmp0 configure
-community public -writecommunity {} -address 194.217.109.79 -port 161 -version SNMPv1 -timeout 5 -retries 3 -window 10 -delay 0
% snmp0 get sysName.0
{1.3.6.1.2.1.1.5.0 {OCTET STRING} frank.cova-tech.com}
% snmp0 set {{sysName.0 frank}}
noSuchName 1 {1.3.6.1.2.1.1.5.0 {OCTET STRING} frank}
#
# configure the session to the private community and demonstrate a set.
#
% snmp0 configure -community private
-community private -writecommunity {} -address 194.217.109.79 -port 161 -version SNMPv1 -timeout 5 -retries 3 -window 10 -delay 0
% snmp0 get sysName.0
{1.3.6.1.2.1.1.5.0 {OCTET STRING} frank.cova-tech.com}
% snmp0 set {{sysName.0 frank}}
{1.3.6.1.2.1.1.5.0 {OCTET STRING} frank}
% snmp0 get sysName.0
{1.3.6.1.2.1.1.5.0 {OCTET STRING} frank}
#
# set the community to public and the write community to private.
# Perform a set and demostrate the bug.
#
% snmp0 configure -community public
-community public -writecommunity {} -address 194.217.109.79 -port 161 -version SNMPv1 -timeout 5 -retries 3 -window 10 -delay 0
% snmp0 configure -writecommunity private
-community public -writecommunity private -address 194.217.109.79 -port 161 -version SNMPv1 -timeout 5 -retries 3 -window 10 -delay 0
% snmp0 get sysName.0
{1.3.6.1.2.1.1.5.0 {OCTET STRING} frank}
% snmp0 set {{sysName.0 frank.cova-tech.com}} 
noResponse
% snmp0 get sysName.0
{1.3.6.1.2.1.1.5.0 {OCTET STRING} frank.cova-tech.com}
%

This was in effect the message I sent to Jurgen Schoenwaelder and here
is the message he sent back:


From: Juergen Schoenwaelder <schoenw@cs.utwente.nl> To:
simon@cova-tech.com Subject: Re: Scotty bug in SNMP sets? maybe...
Date: Thu, 26 Sep 1996 17:45:58 +0200


simon@cova-tech.com (Simon Benn) said:

Simon>	I think I may have found an inconsistancy in the Tnm extesion,
Simon>	specifically in SNMP set requests. Please correct me if I am
Simon>	wrong.

[...]

Simon>	When a SNMP set is performed with the public community and a
Simon>	private write community a noResponse message is generated but
Simon>	the set is still performed.

This is indeed a bug. Below is a work-around. It is not the final
solution because it will accept the writecommunity string for every
response which is not a good idea. Anyway, thanks for reporting this
problem. I am looking forward to see your monitoring app. :-)

							Juergen

*** tnmSnmpRecv.c.orig	Mon Sep  2 17:40:59 1996
--- tnmSnmpRecv.c	Thu Sep 26 17:36:50 1996
***************
*** 450,465 ****
      switch (msg->version) {
  	
      case TNM_SNMPv1:
- 	if (strlen(community) != msg->comLen) break;
- 	authentic = (memcmp(community, msg->com, msg->comLen) == 0);
- 	break;
- 
  #ifdef TNM_SNMPv2C
      case TNM_SNMPv2C:
- 	if (strlen(community) != msg->comLen) break;
- 	authentic = (memcmp(community, msg->com, msg->comLen) == 0);
- 	break;
  #endif
  
  #ifdef TNM_SNMPv2U
      case TNM_SNMPv2U:
--- 450,473 ----
      switch (msg->version) {
  	
      case TNM_SNMPv1:
  #ifdef TNM_SNMPv2C
      case TNM_SNMPv2C:
  #endif
+ 	authentic = ((strlen(community) == msg->comLen) &&
+ 		     (memcmp(community, msg->com, msg->comLen) == 0));
+ 
+ 	/*
+ 	 * XXX
+ 	 * This is not really correct since we should only check the
+ 	 * writeCommunity string for responses to a set operations.
+ 	 */
+ 
+ 	if (! authentic && session->writeCommunity) {
+ 	    community = session->writeCommunity;
+ 	    authentic = ((strlen(community) == msg->comLen) &&
+ 			 (memcmp(community, msg->com, msg->comLen) == 0));
+ 	}
+ 	break;
  
  #ifdef TNM_SNMPv2U
      case TNM_SNMPv2U:


Hope this helps.


