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 <[email protected]> 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 >> [email protected] >> 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 > [email protected] > http://lists.agentpp.org/mailman/listinfo/snmp4j _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
