Re: snmptrap v3 authentication

2023-04-25 Thread Niels Baggesen via Net-snmp-coders

Which trap receiver are you using? snmptrapd, or something else?

/Niels

Den 25-04-2023 kl. 15:10 skrev Simon Chamlian:

I tried the command:

snmptrap -v 3 -u  Simon  -a MD5 -A  SimonPass -l authNoPriv 
172.27.37.227 "" coldStart.0


(with security name  : Simon and  authentication password  : SimonPass ).

These parameters are not set in any config files anywhere.

On another PC with IP 172.27.37.227, I have a MIB browser and trap 
receiver. The trap receiver is receiving the trap even when it is not 
configured with the security name  : Simon and  authentication 
password  : SimonPass .


I was not expecting to receive the trap until I configured the trap 
receiver with the same security name and authentication password!?!


Simon




On Tue, Apr 25, 2023 at 3:17 AM Craig Small via Net-snmp-coders 
 wrote:


On Sat, 15 Apr 2023 at 11:12, Simon Chamlian
 wrote:


snmptrap -v 3 -u  Simon  -a MD5 -A  SimonPass -l authNoPriv
172.27.37.227 "" coldStart.0

I do receive the trap on my Trap Receiver even if I didn't
specify a Username and Authentication password in the MIB
browser (on 172.27.37.227 ) !

Do you mean the security name instead of the username?
The -u sets the security name, -A sets the authentication
password. They're set in the example you gave.

Or are you saying that you tried that command without the username
and authentication password?
If so, are you sure that you don't have those parameters set in an
snmp configuration file?

Trying the command with -Dread_config:line may help here.

I tried snmptrap 5.9.3 with no -u and -A flags and with/without a
configuration file and it only worked with the configuration file.

 - Craig

___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders



___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


--
Niels Baggesen -- @home -- Århus -- Denmark --n...@users.sourceforge.net
   The purpose of computing is insight, not numbers  --  R W Hamming
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: HEX- String instead of Octet - String - incase of inetAddress

2019-12-04 Thread Niels Baggesen via Net-snmp-coders
On Tue, Dec 03, 2019 at 04:45:30PM +, Bek, Anshul wrote:
> 
> For 9.9.156.1.1.2.1.7.1 and 9.9.156.1.1.2.1.7.2, its basically an InetAddress.
> 
> I have 2 queries:
> 
> 
>   1.  Is there any way to get only these 2 InetAddress as Hex-string. I can 
> see that  in sprint_realloc_octet_string() in snmplib/mib.c involves in 
> sprinting OCTET STRINGS for snmpgets and walks. Is there any value to check ? 
> Also  hints, enums and units passed in NULL.
>   2.  Why is the IP display in this manner ie. each octet in ascii . Is it by 
> default ?
> 
> Note:- I don't want to use -Ox option as this will display all the strings 
> value in Hex.

They are display that way because Cisco intended this to be a host name
and then it makes sense that it is a string.

They are defined like this

$ snmptranslate -Td -m ALL SNMPv2-SMI::enterprises.9.9.156.1.1.2.1.2.1
CISCO-CCM-MIB::ccmName.1
ccmName OBJECT-TYPE
  -- FROM   CISCO-CCM-MIB
  -- TEXTUAL CONVENTION SnmpAdminString
  SYNTAXOCTET STRING (0..128) 
  DISPLAY-HINT  "255t"
  MAX-ACCESSread-only
  STATUScurrent
  DESCRIPTION   "The host name of the CallManager."
::= { iso(1) org(3) dod(6) internet(1) private(4)
  enterprises(1) cisco(9) ciscoMgmt(9) ciscoCcmMIB(156)
  ciscoCcmMIBObjects(1) ccmGeneralInfo(1) ccmTable(2)
  ccmEntry(1) ccmName(2) 1 }
  
/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: MAC Address As Index

2019-09-11 Thread Niels Baggesen via Net-snmp-coders
On Wed, Sep 11, 2019 at 12:40:38PM +0530, Krishna Chaitanya wrote:
> > BTW, somehow the response from Neils is missed but found it in the archive.
> >
> > https://www.mail-archive.com/net-snmp-coders@lists.sourceforge.net/msg21705.html
> >
> > MacAddress TC from SNMPv2-TC is a fixed size string, so, the length
> > should not be prefixed.
> >
> 
> Any ideas on how to get proper MAC address display without any side
> effects? Any help is appreciated.

The MacAddress TC mentioned above has a DISPLAY-HINT "1x:", does that
not display the way you want? Otherwise show us what you see, and what
is wrong with it.

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: MAC Address As Index

2019-08-22 Thread Niels Baggesen via Net-snmp-coders
On Tue, Aug 20, 2019 at 06:14:34PM +0530, Krishna Chaitanya wrote:
> Hi,
> 
> When using MAC Address as an index ( I am using MacAddress type from
> SNMPv2-TC.) the output is incorrect because the length of the string
> is prefixed as mac address is defined as OCTET STR there is an extra
> byte and the last byte of mac address is interpreted as next OID.
> 
> snmpwalk:
>HistValue."wlp8s0f0".'B.'.hist_2.2.19
> snmpwalk -OX
>   HistValue["wlp8s0f0"][STRING: 06:00:90:e6:42:99][hist_2][2].19
> 
> In the above examples last but one OID 2 is hist_2. Is there a way to
> disable prefixing of length?

See RFC 2578, clause 7.7. You define your MAC address as an OCTET STRING
(SIZE(6)), then there is no need to prefix the length.

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: Set OID value in code

2019-07-30 Thread Niels Baggesen via Net-snmp-coders
On Mon, Jul 29, 2019 at 03:19:56PM -0400, Ryan Frost wrote:
> Good afternoon,
> 
> I am familiar with the CLI commands and can also get OID values in code but
> I need to set them in code. How do I go about doing this? I’m using
> read_objid to print them similar to the example but I need to be able to
> set the values in code.

man read_objid?

Have you looked at the source of the CLI commands for inspiration?

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: Update UCD-SNMP-MIB variable type

2019-05-13 Thread Niels Baggesen via Net-snmp-coders
On Mon, May 13, 2019 at 10:08:58AM +0200, Ilya Etingof wrote:
> 
> > The currelt 5.8 release (and unreleased 5.7 update) should already
> > contain objects like memTotalRealX which are defined as
> > CounterBasedGauge64
> > 
> > Unfortunately I don't have hardware to test it :-)
> 
> Just in case on-line agent emulation [1] could be helpful:
> 
> $ snmpget -v2c -c mib2dev/ucd-snmp-mib demo.snmplabs.com 
> UCD-SNMP-MIB::memTotalRealX.0
> UCD-SNMP-MIB::memTotalRealX.0 = Counter64: 18345168853242336474 kB
> 
> You can have it off-line as well [2].
> 
> 1. http://demo.snmplabs.com
> 2. http://snmplabs.com/snmpsim

Well, what is interesting is if the real agent get the real value. It
is about debugging the agent running on the physical hardware.

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: Update UCD-SNMP-MIB variable type

2019-05-13 Thread Niels Baggesen via Net-snmp-coders
On Mon, May 13, 2019 at 02:56:46AM -0400, Josef Ridky wrote:
> Hi folks,
> 
> I would like to know your opinion on following issue.
> 
> UCD-SNMP-MIB [1] uses INTEGER32 instead of COUNTER64 for memory OIDs which 
> limits the reporting to 2 TiB (using KiB as the base).
> Large modern servers often contain more than 2 TiB of memory leading to the 
> OIDs rolling over and reporting negative values.
> 
> How can it be solved? 
> Can we just change the variable type? (I don't think so) 
> Or can we add new variables, that will be COUNTER64 type? 
> Or can the base be set to e.g. MiB instead of KiB in configuration?

The currelt 5.8 release (and unreleased 5.7 update) should already
contain objects like memTotalRealX which are defined as
CounterBasedGauge64

Unfortunately I don't have hardware to test it :-)

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: Parsing the values returned from snmp_synch_response

2019-05-03 Thread Niels Baggesen via Net-snmp-coders
On Thu, May 02, 2019 at 05:51:03PM +, Even Oscar Andersen wrote:
> (Repost of message sent to net-snmp-users, maybe this forum is more 
> appropriate)
> 
> Hello,
> 
> I am calling snmp_synch_response, and try to use the resulting variables,
> 
> It seems part of the result return variable type 0x81, not sure what this 
> variable is,
> It is not one of the ASN_ defines, but if I mask out 0x80 (not sure if this 
> is correct),
> It seems to be ASN_BOOLEAN.

This is a SNMPv2 exception type. You can find it in 
include/net-snmp/library/snmp.h,
but here are the exceptions:


/*
 * Exception values for SNMPv2p, SNMPv2c, SNMPv2u, SNMPv2*, and
 * SNMPv3 
  */
#define SNMP_NOSUCHOBJECT(ASN_CONTEXT | ASN_PRIMITIVE | 0x0) /* 80=128 */
#define SNMP_NOSUCHINSTANCE  (ASN_CONTEXT | ASN_PRIMITIVE | 0x1) /* 81=129 */
#define SNMP_ENDOFMIBVIEW(ASN_CONTEXT | ASN_PRIMITIVE | 0x2) /* 82=130 */

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: SNMP Command

2019-05-01 Thread Niels Baggesen via Net-snmp-coders

Den 26-04-2019 kl. 17:22 skrev HOUASLI, Samir via Net-snmp-coders:
I use this command: snmpd -m 
/home/snet/execution/staticCFG/MibCoSNET.txt -v1 -c public localhost .1.3.6.1.4.1.4747.14.5.16.2.0

which allows me to have as an output:

LOG-MIB::sysOperEvalNodeCmdOrder.0 = INTEGER: oper(1)

I want to have as an output the red line which is the description of the 
OID. *Can you tell me which command allows me to have that in the output 
of the terminal?*


You probably meant snmpget not snmpd?

The closest thing we have is snmptranslate with the -Td argument.

But you can of course modify snmpget to your hearts desire :-)

/Niels

--
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: Junk in snmpwalk output

2018-10-05 Thread Niels Baggesen via Net-snmp-coders
On Fri, Oct 05, 2018 at 09:52:07AM +0200, Gisle Vanem via Net-snmp-coders wrote:
> >You should see similar data from IP-MIB in a more readable form.
> 
> Perfect! But I have no idea what a "DISPLAY-HINT" should do.

It will tell how the octets should be presented. Look at IP-MIB, you
will get something like

IP-MIB::ipNetToPhysicalType.4.ipv6."20:01:04:70:df:9a:00:00:00:00:00:00:00:00:00:01"
= INTEGER: dynamic(3)

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: Junk in snmpwalk output

2018-10-04 Thread Niels Baggesen via Net-snmp-coders

Den 05-10-2018 kl. 00:56 skrev Gisle Vanem via Net-snmp-coders:

With this command:
   snmpwalk.exe -M mibs -m ALL -v1 -c public 10.0.0.21

I've getting lines with junk in the output:
   IPV6-MIB::ipv6NetToMediaValid.1.''.12 = INTEGER: true(1)


It is trying to show an OCTET STRING as a string, which in most cases is 
useful but fails miserably for IPv6 addresses which in the IPV6-MIB does 
not have a DISPLAY-HINT.


Try doing snmpwalk with the -Ob option, then you will see something like 
this:


ipv6NetToMediaValid.1.16.255.2.0.0.0.0.0.0.0.0.0.0.0.0.0.12 = INTEGER: 
true(1)


You should see similar data from IP-MIB in a more readable form.

/Niels

--
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: [PATCH / request for votes] SNMP-TARGET-MIB: Fix snmpTargetAddrTAddress

2018-06-18 Thread Niels Baggesen via Net-snmp-coders

Den 18-06-2018 kl. 19:31 skrev Anders Wallin:

+1

but I'm not sure my vote counts, since I was the one reporting the bug


+1, and my vote should count :-)

/Niels

--
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: [PATCH, RFC] Add Travis and Appveyor CI support

2018-05-17 Thread Niels Baggesen via Net-snmp-coders

Den 17-05-2018 kl. 15:54 skrev Robert Story:

On Wed, 16 May 2018 07:23:32 -0700 Bart wrote:
BVA> This patch makes it possible to enable Travis and Appveyor
BVA> continuous integration support. On Travis Net-SNMP is built
BVA> with all MIBs, with --disable-set-support, with
BVA> --enable-mini-agent, with --enable-minimalist and with
BVA> --enable-read-only. All these configurations are built on
BVA> Linux and on OS/X. On Appveyor Net-SNMP is built with MSVC and
BVA> dynamic libraries, with MSVC and statically linked libraryes,
BVA> with MinGW64, with Cygwin32 and with Cygwin64. As one can see
BVA> in the scripts in the "ci" directory the to-do items are as
BVA> follows:

Given that this doesn't affect code and CI support is a good thing:
+1


Another +1

/Niels

--
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: CFV: complete fix for setting engineBoots/Time via cli

2018-05-17 Thread Niels Baggesen via Net-snmp-coders

Den 17-05-2018 kl. 13:48 skrev Robert Story:

A fix in pre2 or pre3 fixed use of -Z command line argument for
setting engineBoots/engineTime. The snmptrap app needs to be fixed
as well.

[PATCH] also fix snmptrap for setting engineBoots and engineTime (e.g. -Z cli 
arg)

An addendum for earlier fix for agent side (commit 988562514b05a2bc01be4)


+1

/Niels

--
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


PATCH at_solaris.c

2018-05-15 Thread Niels Baggesen via Net-snmp-coders
The new at_solaris access module does not compile. May I solicit votes for
this patch for the missing include file?

diff --git a/agent/mibgroup/mibII/data_access/at_solaris.c
b/agent/mibgroup/mibII/data_access/at_solaris.c
index 0a92ec0..b14a999 100644
--- a/agent/mibgroup/mibII/data_access/at_solaris.c
+++ b/agent/mibgroup/mibII/data_access/at_solaris.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include "kernel_sunos5.h"
+#include "../at.h"
 
 typedef struct if_ip {
 int ifIdx;

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: RFC: fix clientaddr for 5.8

2018-05-14 Thread Niels Baggesen via Net-snmp-coders

Den 14-05-2018 kl. 20:05 skrev Robert Story:

+1 on both counts (commit it, but use cherry-pick).


+1 (and I wouldn't mind the OpenBSD part getting merged too)

/Niels

--
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Suggested patch to support NetBSD 8

2018-05-14 Thread Niels Baggesen via Net-snmp-coders
The patch that went into 5.7-patches is not sufficient for NetBSD 8 on
5.8

The following patch to 5.8.RC1 is required.

May I solicit some votes?

diff --git a/agent/mibgroup/mibII/at.h b/agent/mibgroup/mibII/at.h
index 1676cb6..e89b966 100644
--- a/agent/mibgroup/mibII/at.h
+++ b/agent/mibgroup/mibII/at.h
@@ -53,7 +53,7 @@ config_require(mibII/data_access/at_solaris)
 #elif defined(linux)
 config_require(mibII/data_access/at_linux)
 config_require(mibII/data_access/at_unix)
-#elif defined(HAVE_SYS_SYSCTL_H) && defined(RTF_LLINFO)
+#elif defined(HAVE_SYS_SYSCTL_H) && (defined(RTF_LLINFO) || 
defined(RTF_LLDATA))
 config_require(mibII/data_access/at_sysctl)
 config_require(mibII/data_access/at_unix)
 #elif defined(HAVE_NLIST_H)
diff --git a/agent/mibgroup/mibII/data_access/at_sysctl.c 
b/agent/mibgroup/mibII/data_access/at_sysctl.c
index d80228e..dfc207c 100644
--- a/agent/mibgroup/mibII/data_access/at_sysctl.c
+++ b/agent/mibgroup/mibII/data_access/at_sysctl.c
@@ -54,6 +54,8 @@ ARP_Scan_Init(void)
 mib[4] = NET_RT_FLAGS;
 #if defined RTF_LLINFO
 mib[5] = RTF_LLINFO;
+#elif defined(RTF_LLDATA)
+mib[5] = RTF_LLDATA;
 #else
 mib[5] = 0;
 #endif

--
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: [PATCH for master / request for votes] configure.ac: Fix recently introduced autoreconf warnings

2018-05-07 Thread Niels Baggesen via Net-snmp-coders

Den 07-05-2018 kl. 06:13 skrev Bart Van Assche:

A recent patch introduced an invocation of AC_CHECK_HEADER before AC_AIX.
However, AC_AIX must be invoked before AC_CHECK_HEADER. Hence move AC_AIX
from configure.d/config_os_progs into configure.ac. Additionally, since
AC_AIX is obsolete, use AC_USE_SYSTEM_EXTENSIONS instead. This patch fixes
all instances of the following autoreconf warnings:


+1

/Niels

--
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: NET-SNMP version: 5.7.3 and IPv6

2018-01-24 Thread Niels Baggesen via Net-snmp-coders
On Wed, Jan 17, 2018 at 10:58:40AM -0500, Simon Chamlian wrote:
> but these tokens are not recognized:
> ./snmpd.conf: line 12: Warning: Unknown token: rocommunity6.
> ./snmpd.conf: line 13: Warning: Unknown token: rwcommunity6.

This means that snmpd did not understand you config, and accordingly it
does not support community access for IPv6.

Are you sure you are running the version compiled with --enable-ipv6?

What other config options did you use?

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: NET-SNMP version: 5.7.3 and IPv6

2018-01-24 Thread Niels Baggesen via Net-snmp-coders
n Wed, Jan 17, 2018 at 10:58:40AM -0500, Simon Chamlian wrote:
> but these tokens are not recognized:
> ./snmpd.conf: line 12: Warning: Unknown token: rocommunity6.
> ./snmpd.conf: line 13: Warning: Unknown token: rwcommunity6.

This means that snmpd did not understand you config, and accordingly it
does not support community access for IPv6.

Are you sure you are running the version compiled with --enable-ipv6?

What other config options did you use?

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers   ---   R W Hamming

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


Re: [SCM] Net-SNMP branch master updated. v5.7.3-2342-gbe94477

2018-01-11 Thread Niels Baggesen via Net-snmp-coders
On Fri, Dec 15, 2017 at 09:28:37PM +, Robert Story via Net-snmp-cvs wrote:
> commit 9e49de2e03b18ceb1b7cba2e715ad6180f394815
> Author: Robert Story 
> Date:   Thu Dec 14 11:53:13 2017 -0500
> 
> NEWS: snmplib: AES-192/AES-256 compatibility with SNMP Research / CISCO
> 
> - they use key localization algorithm from 
> draft-reeder-snmpv3-usm-3desede-00
>   instead of the Blumenthal draft
> 
> Also:
> - configure option to enable larger AES key length code
> - localized key extension via blumenthal and reeder method

Was it intentional that this silently changed our autoconf requirement
from 2.68 to 2.69?

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers  --  R W Hamming

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders