net-snmp-coders — Discussion of internal project coding (Please use this OR -users, NOT both!)

Connecting sub-agent to Master agent

[RAHUL S. <rah...@gm...>]

Hi All,

Can one sub agent be connected to multiple master agents running on a
system?
If yes, how can that be achieved?

Thanks,
Rahul Sharma.

Getting linker error for Net-snmp. Need help

[<Kir...@de...>]

Please let me know the fix for the same.

# make
making all in /usr/pkg/src/net-snmp-5.8/snmplib
making all in /usr/pkg/src/net-snmp-5.8/agent
making all in /usr/pkg/src/net-snmp-5.8/agent/helpers
making all in /usr/pkg/src/net-snmp-5.8/agent/mibgroup
/bin/sh ../libtool --mode=link gcc -g -O2 -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -DNETSNMP_REMOVE_U64 -g -O2 -Unetbsdelf7 -Dnetbsdelf7=netbsdelf7 -o snmpd snmpd.lo  libnetsnmpagent.la libnetsnmpmibs.la ../snmplib/libnetsnmp.la -lelf -lm
libtool: link: gcc -g -O2 -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -DNETSNMP_REMOVE_U64 -g -O2 -Unetbsdelf7 -Dnetbsdelf7=netbsdelf7 -o .libs/snmpd .libs/snmpd.o  ./.libs/libnetsnmpagent.so ./.libs/libnetsnmpmibs.so /usr/pkg/src/net-snmp-5.8/agent/.libs/libnetsnmpagent.so /usr/pkg/src/net-snmp-5.8/snmplib/.libs/libnetsnmp.so -lkvm ../snmplib/.libs/libnetsnmp.so -lcrypto -lelf -lm  -Wl,-rpath -Wl,/usr/local/lib
./.libs/libnetsnmpmibs.so: undefined reference to `netbsd_read_ip_stat'
./.libs/libnetsnmpmibs.so: undefined reference to `netbsd_read_icmp_stat'
./.libs/libnetsnmpmibs.so: undefined reference to `netbsd_read_icmp6_stat'
./.libs/libnetsnmpmibs.so: undefined reference to `netbsd_read_icmp_msg_stat'
./.libs/libnetsnmpmibs.so: undefined reference to `netbsd_read_icmp6_msg_stat'
./.libs/libnetsnmpmibs.so: undefined reference to `netbsd_read_tcp_stat'
./.libs/libnetsnmpmibs.so: undefined reference to `netbsd_read_udp_stat'

Regards,
Kiran

Re: snmptrapd

[jayshankar n. <jay...@gm...>]

snmptrapd not receiving traps due to firewalld. Once the firewalld is
stopped, i receive traps.

On Wed, Feb 13, 2019 at 6:34 PM Anders Wallin <wal...@gm...> wrote:

> Start snmptrapd with debug traces. e.g. "-DALL -d -Lf /tmp/snmptrapd.log"
>
> Regards
> Anders Wallin
>
>
> On Wed, Feb 13, 2019 at 1:50 PM jayshankar nair <jay...@gm...>
> wrote:
>
>> Hi,
>>
>> I am running snmptrapd on linux machine. I am sending trap from the same
>> machine. I am able to receive trap on snmptrapd log and tcpdump logs.
>> My snmptrapd conf file is as below.
>>
>> authCommunity log,execute,net public
>> createUser -e 0x8000000001020304 traptest SHA mypassword DES mypassword
>> authuser log,execute,net traptest
>> createUser -e 0x8000000001020304 myuser MD5 mypassword
>> authuser log,execute,net myuser.
>>
>> In second scenario i am sending the trap(v2 and v3) from solaris and
>> windows machine. I am able to receive traps on tcpdump. But snmptrapd is
>> unable to receive traps.
>>
>> Thanks,
>> Jayshankar
>> _______________________________________________
>> Net-snmp-coders mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>>
>

Re: snmptrapd

[jayshankar n. <jay...@gm...>]

Hi Anders,

I have attached the snmptrap log. Only error appearing in this log
couldn't connect to /var/agentx/master. Still snmptrapd is unable to
receive v2 traps from remote windows machine.

Thanks,
Jayshankar


On Wed, Feb 13, 2019 at 6:34 PM Anders Wallin <wal...@gm...> wrote:

> Start snmptrapd with debug traces. e.g. "-DALL -d -Lf /tmp/snmptrapd.log"
>
> Regards
> Anders Wallin
>
>
> On Wed, Feb 13, 2019 at 1:50 PM jayshankar nair <jay...@gm...>
> wrote:
>
>> Hi,
>>
>> I am running snmptrapd on linux machine. I am sending trap from the same
>> machine. I am able to receive trap on snmptrapd log and tcpdump logs.
>> My snmptrapd conf file is as below.
>>
>> authCommunity log,execute,net public
>> createUser -e 0x8000000001020304 traptest SHA mypassword DES mypassword
>> authuser log,execute,net traptest
>> createUser -e 0x8000000001020304 myuser MD5 mypassword
>> authuser log,execute,net myuser.
>>
>> In second scenario i am sending the trap(v2 and v3) from solaris and
>> windows machine. I am able to receive traps on tcpdump. But snmptrapd is
>> unable to receive traps.
>>
>> Thanks,
>> Jayshankar
>> _______________________________________________
>> Net-snmp-coders mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>>
>

Re: snmptrapd

[Anders W. <wal...@gm...>]

Start snmptrapd with debug traces. e.g. "-DALL -d -Lf /tmp/snmptrapd.log"

Regards
Anders Wallin


On Wed, Feb 13, 2019 at 1:50 PM jayshankar nair <jay...@gm...>
wrote:

> Hi,
>
> I am running snmptrapd on linux machine. I am sending trap from the same
> machine. I am able to receive trap on snmptrapd log and tcpdump logs.
> My snmptrapd conf file is as below.
>
> authCommunity log,execute,net public
> createUser -e 0x8000000001020304 traptest SHA mypassword DES mypassword
> authuser log,execute,net traptest
> createUser -e 0x8000000001020304 myuser MD5 mypassword
> authuser log,execute,net myuser.
>
> In second scenario i am sending the trap(v2 and v3) from solaris and
> windows machine. I am able to receive traps on tcpdump. But snmptrapd is
> unable to receive traps.
>
> Thanks,
> Jayshankar
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>

snmptrapd

[jayshankar n. <jay...@gm...>]

Hi,

I am running snmptrapd on linux machine. I am sending trap from the same
machine. I am able to receive trap on snmptrapd log and tcpdump logs.
My snmptrapd conf file is as below.

authCommunity log,execute,net public
createUser -e 0x8000000001020304 traptest SHA mypassword DES mypassword
authuser log,execute,net traptest
createUser -e 0x8000000001020304 myuser MD5 mypassword
authuser log,execute,net myuser.

In second scenario i am sending the trap(v2 and v3) from solaris and
windows machine. I am able to receive traps on tcpdump. But snmptrapd is
unable to receive traps.

Thanks,
Jayshankar

Interface specific SNMP security configuration.

[RAHUL S. <rah...@gm...>]

Hi,

I am new to SNMP and I am trying to achieve SNMP security configurations
specific to interface.

I need to have unique SNMP configurations for each available interface.
For example, if I have both wired and wireless supported on device and I
want to configure a v3 user for wired interface, the v3 user should be
accessible only over wired interface. While querying this user over
wireless interface "No user found" error should be returned.

As per the standard configuration, security configurations are written to
snmpd.conf and it is a system wide configuration.

Is there any way to have different snmpd.conf for different interface?

Will I have to run multiple snmpd? If yes, how I can do that. Please note
when I run snmpd, I provide a custom snmpd.conf (using option       -C -c).

Thanks in advance,
Rahul Sharma.

pass_persist counter32

[Michael Wu <mic...@gm...>]

Hi All,

The counter32 value returned from pass_persist script never wraps around on
my system (debian ppc) it remains at 2^32-1 with counter value more than
2^32-1.
In netsnmp_internal_pass_parse() in pass_common.c

    else if (!strncasecmp(buf, "counter", 7)) {
        *var_len = sizeof(long_ret);
        long_ret = strtoul(buf2, NULL, 10);
        vp->type = ASN_COUNTER;
        return ((unsigned char *) &long_ret);

It calls strtoul to convert the value string to long (long is 4 bytes
on my system) so anything more than 2^32-1 will be -1. Should the wrap
around logic happen here? I could use counter64 but just curious if my
understanding is correct.

Appreciate your help,


Michael

Interface specific configuration for SNMP

[RAHUL S. <rah...@gm...>]

Hi,

I am trying to do interface specific configuration in net-snmp.
For example, I create a v3 user for wired interface, I should be able to
contact using that user only on wired IP and not on wireless IP.

Can someone please provide information about this?
Is this kind of configuration supported in net-snmp?

Thanks,
Rahul Sharma.

Re: [PATCH 0/6] Add support for interface binding

[Bill F. <fe...@us...>]

On Fri, Jan 25, 2019 at 11:37 AM Magnus Fromreide <ma...@ly...>
wrote:

> On Sun, Oct 28, 2018 at 01:54:22PM -0700, Bart Van Assche wrote:
> > Hello,
> >
> > As you may have noticed multiple people asked to add SO_BINDTODEVICE
> support
> > to Net-SNMP. This patch series adds such support by allowing to specify
> the
> > name of the network interface to bind a Net-SNMP endpoint to as
> > "@<interface name>". An example:
> >
> > agent/snmpd -Mmibs -f -Lo -c .../snmpd.conf udp6:localhost@lo:1161 -r
> > apps/snmpwalk -Mmibs -v2c -cpublic udp6:localhost:1161 .1
>
> I have no real feeling one way or the other over the patch per se but I
> am wondering if the clash with virtual interface names on linux (e.g.
> lo:1) makes the choosen syntax problematic for the interface name
> parser?
>

This syntax is obsolete.  The supported mechanism is to use iproute2 to
manage multiple addresses/prefixes per interface.

  Bill

Re: [PATCH 0/6] Add support for interface binding

[Magnus F. <ma...@ly...>]

On Sun, Oct 28, 2018 at 01:54:22PM -0700, Bart Van Assche wrote:
> Hello,
> 
> As you may have noticed multiple people asked to add SO_BINDTODEVICE support
> to Net-SNMP. This patch series adds such support by allowing to specify the
> name of the network interface to bind a Net-SNMP endpoint to as
> "@<interface name>". An example:
> 
> agent/snmpd -Mmibs -f -Lo -c .../snmpd.conf udp6:localhost@lo:1161 -r
> apps/snmpwalk -Mmibs -v2c -cpublic udp6:localhost:1161 .1

I have no real feeling one way or the other over the patch per se but I
am wondering if the clash with virtual interface names on linux (e.g.
lo:1) makes the choosen syntax problematic for the interface name
parser?

/MF

Re: [PATCH 0/6] Add support for interface binding

[Bill F. <fe...@us...>]

I was thinking about adding text below the table instead - "When specifying
*hostname*, *IPv4-address* or *IPv6-address* in the tcp, udp, tcp6 or udp6
transports, you can also ...".  I don't want to clutter up the main
documentation with these kind-of-corner-cases.

  Bill


On Fri, Jan 25, 2019 at 3:53 AM Anders Wallin <wal...@gm...> wrote:

> What about something like this ( I skipped the "or")
> diff --git a/man/snmpcmd.1.def b/man/snmpcmd.1.def
> index aea3ca40a..d4f896000 100644
> --- a/man/snmpcmd.1.def
> +++ b/man/snmpcmd.1.def
> @@ -367,12 +367,12 @@ to the following table:
>  .BR "<transport-specifier>"
>  .BR "<transport-address> format"
>  .IP "udp" 28
> -hostname[:port]
> -.I or
> -IPv4-address[:port]
> +hostname[@interface[@namespace]][:port]
> +.IP "" 28
> +IPv4-address[@interface[@namespace]][:port]
>  .IP "tcp" 28
>
> which gives
>             <transport-specifier>       <transport-address> format
>
>              udp
>  hostname[@interface[@namespace]][:port]
>
>
>  IPv4-address[@interface[@namespace]][:port]
>
>
>
> ons 23 jan. 2019 kl 20:38 skrev Bill Fenner <fe...@us...
> >:
>
>> My attempts at updating the man page formats really poorly in 80 columns:
>>
>>        At its simplest, the AGENT specification may consist of a  host-
>>
>>        name, or an IPv4 address in the standard "dotted quad" notation.
>>
>>        In this case, communication will be attempted using UDP/IPv4  to
>>
>>        port  161 of the given host.  Otherwise, the <transport-address>
>>
>>        part of the specification is parsed according to  the  following
>>
>>        table:
>>
>>
>>            <transport-specifier>       <transport-address> format
>>
>>
>>            udp                         hostname[@interface[@names-
>>
>>                                        pace]][:port]                 or
>>
>>                                        IPv4-address[@interface[@names-
>>
>>                                        pace]][:port]
>>
>>
>>            tcp                         hostname[@interface[@names-
>>
>>                                        pace]][:port]                 or
>>
>>                                        IPv4-address[@interface[@names-
>>
>>                                        pace]][:port]
>>
>>
>>            unix                        pathname
>>
>>
>>            ipx                         [network]:node[/port]
>>
>>
>>            aal5pvc or pvc              [interface.][VPI.]VCI
>>
>>
>>            udp6 or udpv6 or udpipv6    hostname[@interface[@names-
>>
>>                                        pace]][:port]                 or
>>
>>                                        IPv6-address[@interface[@names-
>>
>>                                        pace]]:port or
>>
>>                                         '['IPv6-address']'[@inter-
>>
>>                                        face[@namespace]][:port]
>>
>>
>>            tcp6 or tcpv6 or tcpipv6    hostname[@interface[@names-
>>
>>                                        pace]][:port]                 or
>>
>>                                        IPv6-address[@interface[@names-
>>
>>                                        pace]]:port or
>>
>>                                         '['IPv6-address']'[@inter-
>>
>>                                        face[@namespace]][:port]
>>
>> ...
>>
>>        udp:hostname            identical to the previous specification.
>>
>>                                The   "udp:"  is  redundant  here  since
>>
>>                                UDP/IPv4 is the default transport.
>>
>>
>>        hostname@eth0:161       identical to the previous specification,
>>
>>                                except  that the communication is forced
>>
>>                                to eth0 using the SO_BINDTODEVICE socket
>>
>>                                option.
>>
>>
>>        hostname@eth0@blue      identical to the previous specification,
>>
>>                                except  that  the  communication  occurs
>>
>>                                using  the  eth0  interface  inside  the
>>
>>                                namespace named "blue"  (created,  e.g.,
>>
>>                                using ip netns add ).
>>
>> ...
>>
>>        If the platform supports  binding  to  an  interface  using  the
>>
>>        SO_BINDTODEVICE socket option, the optional @interface specifier
>>
>>        can be added to an IP address or host name.
>>
>>
>>        If the platform supports network namespaces using the setns sys-
>>
>>        tem  call,  the  optional @netns specifier can be added to an IP
>>
>>        address or host name.  If an interface specification (see above)
>>
>>        is not required, two @ s are used, e.g., 127.0.0.1@@blue .
>>
>>
>> Perhaps I can fix the formatting of the first table by separating out the
>> "hostname or ip_ address" and "followed by optional @interface, @namespace,
>> :port"? Any suggestions?
>>
>>
>> Thanks,
>>
>>   Bill
>>
>>
>>

Re: SNMPv3 GET/SET issue due to OpenSSL dependency

[prabu v. <pra...@gm...>]

Thanks for the response, Wes.

The mentioned issue has been resolved now. The RCA of the issue is the
build server(Alice) had OpenSSL libraries in two locations /usr/lib and
/usr/local/lib due to this the Net-SNMP was not able to fetch the right
configuration. (This dual lib issue caused due to upgrade and downgrade as
mentioned earlier)

After removing the libraries and config from /usr/local/lib/, I'm able to
verify the SNMPv3 functionality. And also I'd like to share I added
--with-openssl=/usr/lib/openssl in configuration option, without this
change I was not able to achieve the requirement(including
--with-openssl=internal). So please let me know is this expected behaviour.

And there is no specific reason for using the Net-SNMP-5.4.4 package. I'm
using it as the OpenWRT framework has this package support by default. I
will check how can I upgrade the OpenWRT package.

Please let me know if I'm using --with-openssl=internal option whether I'll
be able to achieve the complete functionality of SNMPv3. So that I'll use
--with-openssl=internal instead of --with-openssl=/usr/lib/openssl.

On Wed, Jan 23, 2019 at 8:14 PM Wes Hardaker <har...@us...>
wrote:

>
> Essentially the Net-SNMP configure script looks for functions to
> determine the level of openssl support in configure.in near line 4643
> and you might refer to those checks for determining why you're not
> getting support for the algorithms you want.
>
> Is there any reason you're not using a newer Net-SNMP release?  5.4 is
> really overdue for being dropped from support.  And the newer versions
> have better SSL checks.  You can also specify --with-openssl=internal
> to avoid issues with linking to external openssl packages.
>
> --
> Wes Hardaker
> Please mail all replies to net...@li...
>


-- 
With Best Regards,
Anandaprabu V <https://www.linkedin.com/in/anandaprabu-v-10867671/>
VVDN Technologies Pvt. Ltd <http://www.vvdntech.com/>, Chennai
Cell : +91 9500650885 | Skype : prabuvaradharajan

Re: [PATCH 0/6] Add support for interface binding

[Anders W. <wal...@gm...>]

What about something like this ( I skipped the "or")
diff --git a/man/snmpcmd.1.def b/man/snmpcmd.1.def
index aea3ca40a..d4f896000 100644
--- a/man/snmpcmd.1.def
+++ b/man/snmpcmd.1.def
@@ -367,12 +367,12 @@ to the following table:
 .BR "<transport-specifier>"
 .BR "<transport-address> format"
 .IP "udp" 28
-hostname[:port]
-.I or
-IPv4-address[:port]
+hostname[@interface[@namespace]][:port]
+.IP "" 28
+IPv4-address[@interface[@namespace]][:port]
 .IP "tcp" 28

which gives
            <transport-specifier>       <transport-address> format

             udp
 hostname[@interface[@namespace]][:port]


 IPv4-address[@interface[@namespace]][:port]



ons 23 jan. 2019 kl 20:38 skrev Bill Fenner <fe...@us...>:

> My attempts at updating the man page formats really poorly in 80 columns:
>
>        At its simplest, the AGENT specification may consist of a  host-
>
>        name, or an IPv4 address in the standard "dotted quad" notation.
>
>        In this case, communication will be attempted using UDP/IPv4  to
>
>        port  161 of the given host.  Otherwise, the <transport-address>
>
>        part of the specification is parsed according to  the  following
>
>        table:
>
>
>            <transport-specifier>       <transport-address> format
>
>
>            udp                         hostname[@interface[@names-
>
>                                        pace]][:port]                 or
>
>                                        IPv4-address[@interface[@names-
>
>                                        pace]][:port]
>
>
>            tcp                         hostname[@interface[@names-
>
>                                        pace]][:port]                 or
>
>                                        IPv4-address[@interface[@names-
>
>                                        pace]][:port]
>
>
>            unix                        pathname
>
>
>            ipx                         [network]:node[/port]
>
>
>            aal5pvc or pvc              [interface.][VPI.]VCI
>
>
>            udp6 or udpv6 or udpipv6    hostname[@interface[@names-
>
>                                        pace]][:port]                 or
>
>                                        IPv6-address[@interface[@names-
>
>                                        pace]]:port or
>
>                                         '['IPv6-address']'[@inter-
>
>                                        face[@namespace]][:port]
>
>
>            tcp6 or tcpv6 or tcpipv6    hostname[@interface[@names-
>
>                                        pace]][:port]                 or
>
>                                        IPv6-address[@interface[@names-
>
>                                        pace]]:port or
>
>                                         '['IPv6-address']'[@inter-
>
>                                        face[@namespace]][:port]
>
> ...
>
>        udp:hostname            identical to the previous specification.
>
>                                The   "udp:"  is  redundant  here  since
>
>                                UDP/IPv4 is the default transport.
>
>
>        hostname@eth0:161       identical to the previous specification,
>
>                                except  that the communication is forced
>
>                                to eth0 using the SO_BINDTODEVICE socket
>
>                                option.
>
>
>        hostname@eth0@blue      identical to the previous specification,
>
>                                except  that  the  communication  occurs
>
>                                using  the  eth0  interface  inside  the
>
>                                namespace named "blue"  (created,  e.g.,
>
>                                using ip netns add ).
>
> ...
>
>        If the platform supports  binding  to  an  interface  using  the
>
>        SO_BINDTODEVICE socket option, the optional @interface specifier
>
>        can be added to an IP address or host name.
>
>
>        If the platform supports network namespaces using the setns sys-
>
>        tem  call,  the  optional @netns specifier can be added to an IP
>
>        address or host name.  If an interface specification (see above)
>
>        is not required, two @ s are used, e.g., 127.0.0.1@@blue .
>
>
> Perhaps I can fix the formatting of the first table by separating out the
> "hostname or ip_ address" and "followed by optional @interface, @namespace,
> :port"? Any suggestions?
>
>
> Thanks,
>
>   Bill
>
>
>

Re: [PATCH 0/6] Add support for interface binding

[Bill F. <fe...@us...>]

On Wed, Jan 23, 2019 at 10:17 PM Bart Van Assche <bva...@ac...> wrote:

> On 1/23/19 9:43 AM, Bill Fenner wrote:
> > The pattern I was trying to follow from the existing code appeared to be
> > basically
> >
> > if (cp == delimiter of optional section) {
> >      *cp = '\0'; /* terminate previous section at delimiter */
> >      this = cp + 1; /* handle this section */
> >      cp = ... /* find next optional delimiter or NULL */
> > }
> >
> > Are you suggesting instead to put the "find next optional delimiter"
> > code between sections, e.g.,
> >
> > /* parse IP address, cp still points at beginning of address */
> > maybeintf = strchr( cp, '@' );
> > if (maybeintf) {
> >     *maybeintf = '\0';
> >     cp = maybeintf + 1;
> >     intf = cp;
> > }
> > maybens = strchr( cp, '@' );
> > if (maybens) {
> > ...
> > }
> > maybeport = strchr( cp, ':' );
> > if (maybeport) {
> > ...
> > }
>
> Hi Bill,
>
> No matter which approach will be chosen, please add test cases into
> testing/fulltests/unit-tests/T022netsnmp_parse_ep_str_clib.c.


There are several new test cases for namespace names in what’s on github
now, and in a revision I haven’t pushed yet I added some corner cases like
“hostname@@“ and “hostname@@:”. Was there anything else you thought was
missing?

(Thanks for having written that test, by the way; it helped me find a bug
in my initial code.)

Thanks,
  Bill

Re: [PATCH 0/6] Add support for interface binding

[Bart V. A. <bva...@ac...>]

On 1/23/19 9:43 AM, Bill Fenner wrote:
> The pattern I was trying to follow from the existing code appeared to be 
> basically
> 
> if (cp == delimiter of optional section) {
>      *cp = '\0'; /* terminate previous section at delimiter */
>      this = cp + 1; /* handle this section */
>      cp = ... /* find next optional delimiter or NULL */
> }
> 
> Are you suggesting instead to put the "find next optional delimiter" 
> code between sections, e.g.,
> 
> /* parse IP address, cp still points at beginning of address */
> maybeintf = strchr( cp, '@' );
> if (maybeintf) {
>     *maybeintf = '\0';
>     cp = maybeintf + 1;
>     intf = cp;
> }
> maybens = strchr( cp, '@' );
> if (maybens) {
> ...
> }
> maybeport = strchr( cp, ':' );
> if (maybeport) {
> ...
> }

Hi Bill,

No matter which approach will be chosen, please add test cases into 
testing/fulltests/unit-tests/T022netsnmp_parse_ep_str_clib.c.

Thanks,

Bart.

Re: [PATCH 0/6] Add support for interface binding

[Bill F. <fe...@us...>]

My attempts at updating the man page formats really poorly in 80 columns:

       At its simplest, the AGENT specification may consist of a  host-

       name, or an IPv4 address in the standard "dotted quad" notation.

       In this case, communication will be attempted using UDP/IPv4  to

       port  161 of the given host.  Otherwise, the <transport-address>

       part of the specification is parsed according to  the  following

       table:


           <transport-specifier>       <transport-address> format


           udp                         hostname[@interface[@names-

                                       pace]][:port]                 or

                                       IPv4-address[@interface[@names-

                                       pace]][:port]


           tcp                         hostname[@interface[@names-

                                       pace]][:port]                 or

                                       IPv4-address[@interface[@names-

                                       pace]][:port]


           unix                        pathname


           ipx                         [network]:node[/port]


           aal5pvc or pvc              [interface.][VPI.]VCI


           udp6 or udpv6 or udpipv6    hostname[@interface[@names-

                                       pace]][:port]                 or

                                       IPv6-address[@interface[@names-

                                       pace]]:port or

                                        '['IPv6-address']'[@inter-

                                       face[@namespace]][:port]


           tcp6 or tcpv6 or tcpipv6    hostname[@interface[@names-

                                       pace]][:port]                 or

                                       IPv6-address[@interface[@names-

                                       pace]]:port or

                                        '['IPv6-address']'[@inter-

                                       face[@namespace]][:port]

...

       udp:hostname            identical to the previous specification.

                               The   "udp:"  is  redundant  here  since

                               UDP/IPv4 is the default transport.


       hostname@eth0:161       identical to the previous specification,

                               except  that the communication is forced

                               to eth0 using the SO_BINDTODEVICE socket

                               option.


       hostname@eth0@blue      identical to the previous specification,

                               except  that  the  communication  occurs

                               using  the  eth0  interface  inside  the

                               namespace named "blue"  (created,  e.g.,

                               using ip netns add ).

...

       If the platform supports  binding  to  an  interface  using  the

       SO_BINDTODEVICE socket option, the optional @interface specifier

       can be added to an IP address or host name.


       If the platform supports network namespaces using the setns sys-

       tem  call,  the  optional @netns specifier can be added to an IP

       address or host name.  If an interface specification (see above)

       is not required, two @ s are used, e.g., 127.0.0.1@@blue .


Perhaps I can fix the formatting of the first table by separating out the
"hostname or ip_ address" and "followed by optional @interface, @namespace,
:port"? Any suggestions?


Thanks,

  Bill

Re: [PATCH 0/6] Add support for interface binding

[Bill F. <fe...@us...>]

On Wed, Jan 23, 2019 at 12:58 AM Anders Wallin <wal...@gm...> wrote:

> Hi Bill,
>
> I'm missing updates to the documentation/man pages. (I can't find that the
> man pages are update with @iface either)
>

Yes, I documented it in the same place as @intf ;-)

I'll fix that.

  Bill

Re: [PATCH 0/6] Add support for interface binding

[Bill F. <fe...@us...>]

On Wed, Jan 23, 2019 at 12:15 AM Bart Van Assche <bva...@ac...> wrote:

> On 1/22/19 12:40 PM, Bill Fenner wrote:
> > On Wed, Nov 7, 2018 at 1:26 AM Bart Van Assche <bva...@ac...
> > <mailto:bva...@ac...>> wrote:
> >
> >     On 11/6/18 8:03 AM, Bill Fenner wrote:
> >      > Given your proposed code structure, I imagine that we could add
> >     network
> >      > namespaces to netsnmp_ep too - this basically ends up using
> >     "socketat(
> >      > /* magic */, family, type, protocol )" instead of socket() to
> >     create the
> >      > socket, and the magic can be derived from what we store in ep.
> >
> >     That sounds like a good idea to me.
> >
> >
> > I've finally done this, and would like to request some eyes on it before
> > I push it to 5-8-patches.
> >
> >
> https://github.com/fenner/net-snmp/compare/V5-8-patches...fenner:linux-namespace
>
> Hi Bill,
>
> The following new code in netsnmp_parse_ep_str() looks a bit fragile to me:
>
>              cp = strchr(iface, '@');
>              if (!cp)
>                  cp = strchr(iface, ':');
>
> Wouldn't it be better to backtrack to the previous value of 'cp' if no
> second '@' sign is found? That will avoid that this code fails if
> support for a new delimiter between '@' and ':' would be added.
>

The pattern I was trying to follow from the existing code appeared to be
basically

if (cp == delimiter of optional section) {
    *cp = '\0'; /* terminate previous section at delimiter */
    this = cp + 1; /* handle this section */
    cp = ... /* find next optional delimiter or NULL */
}

Are you suggesting instead to put the "find next optional delimiter" code
between sections, e.g.,

/* parse IP address, cp still points at beginning of address */
maybeintf = strchr( cp, '@' );
if (maybeintf) {
   *maybeintf = '\0';
   cp = maybeintf + 1;
   intf = cp;
}
maybens = strchr( cp, '@' );
if (maybens) {
...
}
maybeport = strchr( cp, ':' );
if (maybeport) {
...
}

where at the end of each block, cp still points to the beginning of the
thing that was parsed by the block (address, intf, namespace, or port) and
we advance the pointer between blocks?


The following code looks unusual to me:
>
> #ifdef HAVE_SETNS
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <sys/socket.h>
> #include <unistd.h>
> #include <signal.h>
> #include <sched.h>
> #include <net-snmp/library/snmp_assert.h>
> #endif
>
> I'm not aware of any other Net-SNMP code that guards include directives
> with the result of a test for a system call.
>

Well, I was just trying to reduce the #include footprint to match the new
code - if the new code in netsnmp_socketat() isn't compiled, then the new
#includes that it requires aren't required.  Maybe this is a leftover habit
from learning C in the 1980's :-)

  Bill

Re: SNMPv3 GET/SET issue due to OpenSSL dependency

[Wes H. <har...@us...>]

Essentially the Net-SNMP configure script looks for functions to
determine the level of openssl support in configure.in near line 4643
and you might refer to those checks for determining why you're not
getting support for the algorithms you want.

Is there any reason you're not using a newer Net-SNMP release?  5.4 is
really overdue for being dropped from support.  And the newer versions
have better SSL checks.  You can also specify --with-openssl=internal
to avoid issues with linking to external openssl packages.

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Change default rwuser default security level

[Wes H. <har...@us...>]

Robert Story <rs...@fr...> writes:

> How about a migration path? Add a warning at startup if rwuser is
> specified without a level. i.e. "Warning: no securityLevel
> specified for rwuser; defaulting to auth".

I think a warning is a good middle ground.

The question you're really asking is: is this default of auth without priv a sensible one or something that is worth breaking running code at some point?  Are we willing to cause existing working config systems to break because we believe that encryption is important enough that we're willing to cause them pain?  It may be, and I'm not saying otherwise, but it isn't a decision we should take lightly.

In the end, which is more important: stability and backward comparability or ensuring people default to "with encryption required".  Is it worth *turning off* support for rwuser?  Is it better to do that than having two tokens, and switching all docs/etc to the new one and just warning against the old?  What's the benefit to deprecation vs obsolesce but still leave it working?

As mentioned, this is well documented in the manual page:

By  default,  this will provide access to the full OID
tree for authenticated (including  encrypted)  SNMPv3  requests,
using  the  default  context.   An  alternative minimum security
level can be specified using noauth  (to  allow  unauthenticated
requests), or priv (to enforce use of encryption).

And does derive from a time where encryption was actually impossible for many.  We'd certainly make the default different if we wrote that code today.

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: [PATCH 0/6] Add support for interface binding

[Anders W. <wal...@gm...>]

Hi Bill,

I'm missing updates to the documentation/man pages. (I can't find that the
man pages are update with @iface either)

BR
Anders

ons 23 jan. 2019 kl 06:16 skrev Bart Van Assche <bva...@ac...>:

> On 1/22/19 12:40 PM, Bill Fenner wrote:
> > On Wed, Nov 7, 2018 at 1:26 AM Bart Van Assche <bva...@ac...
> > <mailto:bva...@ac...>> wrote:
> >
> >     On 11/6/18 8:03 AM, Bill Fenner wrote:
> >      > Given your proposed code structure, I imagine that we could add
> >     network
> >      > namespaces to netsnmp_ep too - this basically ends up using
> >     "socketat(
> >      > /* magic */, family, type, protocol )" instead of socket() to
> >     create the
> >      > socket, and the magic can be derived from what we store in ep.
> >
> >     That sounds like a good idea to me.
> >
> >
> > I've finally done this, and would like to request some eyes on it before
> > I push it to 5-8-patches.
> >
> >
> https://github.com/fenner/net-snmp/compare/V5-8-patches...fenner:linux-namespace
>
> Hi Bill,
>
> The following new code in netsnmp_parse_ep_str() looks a bit fragile to me:
>
>              cp = strchr(iface, '@');
>              if (!cp)
>                  cp = strchr(iface, ':');
>
> Wouldn't it be better to backtrack to the previous value of 'cp' if no
> second '@' sign is found? That will avoid that this code fails if
> support for a new delimiter between '@' and ':' would be added.
>
> The following code looks unusual to me:
>
> #ifdef HAVE_SETNS
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <sys/socket.h>
> #include <unistd.h>
> #include <signal.h>
> #include <sched.h>
> #include <net-snmp/library/snmp_assert.h>
> #endif
>
> I'm not aware of any other Net-SNMP code that guards include directives
> with the result of a test for a system call.
>
> Otherwise the code looks fine to me. But please keep in mind that I only
> had a quick look at it.
>
> Bart.
>
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>

Re: [PATCH 0/6] Add support for interface binding

[Bart V. A. <bva...@ac...>]

On 1/22/19 12:40 PM, Bill Fenner wrote:
> On Wed, Nov 7, 2018 at 1:26 AM Bart Van Assche <bva...@ac... 
> <mailto:bva...@ac...>> wrote:
> 
>     On 11/6/18 8:03 AM, Bill Fenner wrote:
>      > Given your proposed code structure, I imagine that we could add
>     network
>      > namespaces to netsnmp_ep too - this basically ends up using
>     "socketat(
>      > /* magic */, family, type, protocol )" instead of socket() to
>     create the
>      > socket, and the magic can be derived from what we store in ep.
> 
>     That sounds like a good idea to me.
> 
> 
> I've finally done this, and would like to request some eyes on it before 
> I push it to 5-8-patches.
> 
> https://github.com/fenner/net-snmp/compare/V5-8-patches...fenner:linux-namespace

Hi Bill,

The following new code in netsnmp_parse_ep_str() looks a bit fragile to me:

             cp = strchr(iface, '@');
             if (!cp)
                 cp = strchr(iface, ':');

Wouldn't it be better to backtrack to the previous value of 'cp' if no 
second '@' sign is found? That will avoid that this code fails if 
support for a new delimiter between '@' and ':' would be added.

The following code looks unusual to me:

#ifdef HAVE_SETNS
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/socket.h>
#include <unistd.h>
#include <signal.h>
#include <sched.h>
#include <net-snmp/library/snmp_assert.h>
#endif

I'm not aware of any other Net-SNMP code that guards include directives 
with the result of a test for a system call.

Otherwise the code looks fine to me. But please keep in mind that I only 
had a quick look at it.

Bart.

Re: [PATCH 0/6] Add support for interface binding

[Bill F. <fe...@us...>]

On Wed, Nov 7, 2018 at 1:26 AM Bart Van Assche <bva...@ac...> wrote:

> On 11/6/18 8:03 AM, Bill Fenner wrote:
> > Given your proposed code structure, I imagine that we could add network
> > namespaces to netsnmp_ep too - this basically ends up using "socketat(
> > /* magic */, family, type, protocol )" instead of socket() to create the
> > socket, and the magic can be derived from what we store in ep.
>
> That sounds like a good idea to me.
>

I've finally done this, and would like to request some eyes on it before I
push it to 5-8-patches.

https://github.com/fenner/net-snmp/compare/V5-8-patches...fenner:linux-namespace

Thanks,
  Bill

RE: Netsnmpv5.8 possible security flaw

[Madhusudhana R <mad...@in...>]

Hi Robert, 

I checked Wes's theory and 'YES' it is defaulting to 'auth' when no explicit mandate for encryption is done. 

In vacm_create_simple() function, below code defaults to 'auth' when 'priv' token is not explicitly mentioned.  

        if (cp && *cp)
            cp = copy_nword(cp, authlevel, sizeof(authlevel));
        else
            strcpy(authlevel, "auth");

Regards,
Madhu

-----Original Message-----
From: NetSNMP Mailbox <net...@fr...> On Behalf Of Robert Story
Sent: Saturday, January 19, 2019 4:53 AM
To: Madhusudhana R <mad...@in...>
Cc: net...@li...
Subject: Re: Netsnmpv5.8 possible security flaw

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Hi Madhusudhana,

Did you go back and confirm Wes' theory? Did you see an authPriv request which failed, followed by and auth request that succeeded?

Robert


On Wed, 9 Jan 2019 04:19:28 +0000 Madhusudhana wrote:
MR> Thanks Wes.
MR>
MR> -----Original Message-----
MR> From: Wes Hardaker [mailto:har...@us...]
MR> Sent: Tuesday, January 08, 2019 10:08 PM
MR>
MR> Madhusudhana R <mad...@in...> writes:
MR>
MR> > Can you please let me know whether this feature is added newly in 
MR> > v5.8 or it was an existing feature in v5.7.3 ?
MR> > If it is a new feature in v5.8, is there a way to toggle some 
MR> > MACRO value to make sure an user with authpriv protocol will 
MR> > always responds in encrypted way?
MR>
MR> It's not new at all; that behavior has been around since the 
MR> creation of the SNMPv3 code within Net-SNMP (which at the time was 
MR> called UCD-SNMP, showing how old this concept is).  At the time, 
MR> encryption wasn't even possible for everyone deploying the code (and 
MR> the only encryption supported was DES).  The world tended to also 
MR> believe that authentication (ensuring packets weren't modified) was 
MR> a "must have" but encryption was merely a "would be nice if you 
MR> could, but it's not critical".