Hi Binh, Can you reproduce the same behavior with the unmodified SampleAgent? If not, then you have missed a necessary configuration for your setup.
You are right, that the AgentConfigManager should setup the community MIB correctly, but that also depends on a couple of other prerequisites. Regarding 3.: The quoted log does not show the result of the SNMP query because you grep for "secret"which must not be in the output anyway. Best regards, Frank Am 12.01.2012 08:40, schrieb Binh Le: > Hi Frank, > > Thanks a lot for getting back to my question. I was using an Agent > derived from AgentConfigManager - and configure > snmpCommunityTable/vacm tables via snmpset command line from NetSNMP, > nothing special, no code involve..So I would assume that the > co-existence between snmpCommunityTable and other VACM tables are > handled in AgentConfigManager already. > > To answer your questions: > > 1. The "secret" snmpCommunityName had been existed before, with > corresponding mapping to vacmSecurityToGroup and other related tables, > with full read-write access to the whole SNMP tree starting from 1. I > removed the entry as you don't see it in the quoted MIBwalk result of > snmpCommunityTable in my first email. Another MIBwalk from top with a > grepping of "secret" show that there is no any existence of "secret" > in the whole MIB tree. > 2. So it was removed successfully - see (1) above. > 3. Yes, it still works after that. I issue snmpwalk using the > community string "secret" in the example. > > Any suggestion where I should look at and/or check? > > Thanks, > Binh > > > On Sun, Jan 8, 2012 at 2:37 PM, Frank Fock<f...@agentpp.com> wrote: >> Hi, >> >> What agent are you using (i.e., SampleAgent)? >> From the output you quoted, I cannot see >> 1. that a "secrect" community existed and >> 2. that it was removed successfully and >> 3. that it does still work after that. >> >> Have you set the CoexistenceProvider of the BaseAgent >> to your CommunityMIB instance? >> >> Although keep in mind, that the access restrictions are >> handled by the VACM. The Community MIB only provides >> mapping (coexistance) information. If the Community >> MIB implementation is not set as coexistance information >> provider, the community name is directly used as security >> name by SNMP4J-Agent. >> >> Best regards, >> Frank >> >> >> Am 06.01.2012 01:05, schrieb Binh Le: >>> Hi all, >>> >>> I have an entry in snmpCommunityTable with snmpCommunityName "secret". >>> After removing the entry by setting the corresponding >>> snmpCommunityStatus to 'destroy', it's expect that I should not be >>> able to mibwalk using the community string "secret" any more. However, >>> it still works as seen below: >>> >>> lpbinh$ snmpwalk -v 2c -c secret 10.175.53.15 snmpCommunityTable >>> >>> SNMP-COMMUNITY-MIB::snmpCommunityName.'abcd' = STRING: "abcdef" >>> SNMP-COMMUNITY-MIB::snmpCommunitySecurityName.'abcd' = STRING: abcdef >>> SNMP-COMMUNITY-MIB::snmpCommunityContextEngineID.'abcd' = Hex-STRING: >>> 80 00 93 FE 43 6F 72 61 69 64 >>> SNMP-COMMUNITY-MIB::snmpCommunityContextName.'abcd' = STRING: >>> SNMP-COMMUNITY-MIB::snmpCommunityTransportTag.'abcd' = STRING: >>> SNMP-COMMUNITY-MIB::snmpCommunityStorageType.'abcd' = INTEGER: volatile(2) >>> SNMP-COMMUNITY-MIB::snmpCommunityStatus.'abcd' = INTEGER: active(1) >>> SNMP-COMMUNITY-MIB::snmpCommunityStatus.'abcd' = No more variables >>> left in this MIB View (It is past the end of the MIB tree) >>> >>> lpbinh$ lpbinh$ snmpwalk -v 2c -c secret 10.175.53.15 1 | grep secret >>> lpbinh$ >>> >>> Same behavior when I remove the entry via >>> communityMIB.removeSnmpCommunityString(index) . >>> >>> Any comment/suggestion for the pure delete? Otherwise, this may be >>> considered as a security hole. >>> >>> Thanks, >>> Binh. >>> _______________________________________________ >>> SNMP4J mailing list >>> SNMP4J@agentpp.org >>> http://lists.agentpp.org/mailman/listinfo/snmp4j >> -- >> --- >> AGENT++ >> Maximilian-Kolbe-Str. 10 >> 73257 Koengen, Germany >> https://agentpp.com >> Phone: +49 7024 8688230 >> Fax: +49 7024 8688231 >> >> _______________________________________________ >> SNMP4J mailing list >> SNMP4J@agentpp.org >> http://lists.agentpp.org/mailman/listinfo/snmp4j -- --- AGENT++ Maximilian-Kolbe-Str. 10 73257 Koengen, Germany https://agentpp.com Phone: +49 7024 8688230 Fax: +49 7024 8688231 _______________________________________________ SNMP4J mailing list SNMP4J@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j
