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

Re: Source Address based Configuration Control in SNMP Agent

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

Thanks for the response, Wes.

But as per the design, my agent will be configured with only one user which
can be updated as rouser or rwuser. So can you please suggest any other way
to achieve this if possible?

On Mon, Dec 17, 2018 at 11:01 PM Wes Hardaker <
har...@us...> wrote:

> prabu varadharajan <pra...@gm...> writes:
>
> > createUser admin MD5 password AES password123
> > rwuser admin priv
>
> Those lines will provide you the ability for the 'admin' user to
> configure the mibs in question.  To have a different manager only use
> "read-only" support, then create a different user with something like
> this:
>
> createUser adminro MD5 otherpassword AES otherpassword123
> rouser adminro priv
>
> Which will restrict the 'rouser' user to only allow monitoring.
> --
> 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/>, Noida
Cell : +91 9500650885 | Skype : prabuvaradharajan

Re: IF-MIB::ifOperStatus

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

Josef Ridky <jr...@re...> writes:

> I am trying to find, where is IF-MIB::ifOperStatus value taken from on Linux.
> Can someone point me to the correct file?

it's in the agent/mibgroup/if-mib/data_access/ directory, and I *think*
it's in interface_ioctl.c specifically.
-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Source Address based Configuration Control in SNMP Agent

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

prabu varadharajan <pra...@gm...> writes:

> createUser admin MD5 password AES password123
> rwuser admin priv

Those lines will provide you the ability for the 'admin' user to
configure the mibs in question.  To have a different manager only use
"read-only" support, then create a different user with something like
this:

createUser adminro MD5 otherpassword AES otherpassword123
rouser adminro priv

Which will restrict the 'rouser' user to only allow monitoring.
-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: List of RFCs supported by net-snmp version 5.7.3

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

Venkateswarlu Konamki <ven...@gm...> writes:

Sorry for the long delay in responding:

> RFC 2737: Entity MIB (Version 2) 
> RFC 3246: Expedited PHB                                                

Nope, we don't have support for these unfortunately.

But we do for these:

> RFC 2863: MIB (Interfaces Group)                                       
> RFC 3411: Architecture for SNMP Management Frameworks                  
> RFC 3412: Message Processing and Dispatching for the Simple Network    
> Management Protocol (SNMP)                                             
> RFC 3413: SNMP Applications                                            
> RFC 3414: User-based Security Model (USM) for Version 3 of the Simple  
> Network Management Protocol (SNMPv3)                                   
> RFC 3415: View-based Access Control Model                              
> RFC 3416: V2 of SNMP Protocol Operations                               
> RFC 3417: Transport Mappings for the Simple Network Management Protocol
> (SNMP)                                                                 

This there is only half-working support for I believe (it would require
modifications for specific systems before deploying):

> RFC 4502: Remote Monitoring Management Information Base Version 2      

> ifeq ($(strip ${BR2_PACKAGE_NETSNMP_SNMPV3}),y)
> NETSNMP_CONFIG +=       --with-default-snmp-version="3" \
>                         --with-mib-modules="snmpv3mibs mibII utilities/execute" \
>                         --with-out-mib-modules="ucd_snmp utilities notification
> notification-log-mib target agent_mibs agentx disman/event-mib disman/schedule host"

You're removing support for the target mib, which is part of the SNMPv3
specs and is needed by some of the other mibs (snmp configurable
notification support).  The notification-log-mib is too, but may not be
actually needed.

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

Re: Source Address based Configuration Control in SNMP Agent

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

Hi Michael

Thanks for the response. I have gone through the man pages completely
before dropping the mail in the forum. But I could not able to grab the
exact configuration for SNMPv3.

Can you please help me how the VACM will help to fulfil my requirement in
case of SNMPv3?

On Sun, Dec 16, 2018 at 2:34 AM Michael Schwartzkopff <ms...@sy...> wrote:

> Am 15.12.18 um 15:11 schrieb prabu varadharajan:
>
> Dear All,
>
> As per my implementation, I would like to have only one Manager in my
> network who can configure my device, rest all can read the configuration.
> For example, even multiple NMS available in the network which can read the
> configuration(GET) where *only one NMS can write the configurations*(SET).
>
> This can be achieved by adding the following directive in snmpd.conf in
> case of SNMPv1 and SNMPv3,
>
> rwcommunity public 192.168.1.1
>
> But how can I achieve the same in case of SNMPv3? Please advise.
>
> If my Agent is configured in SNMPv3, the following directives will be
> available in the snmpd.conf file,
>
> createUser admin MD5 password AES password123
> rwuser admin priv
>
> I tried to do the source filtering whenever the agent receives a packet and
> able to achieve the same by updating the snmpUDPDomain.c and
> snmpUDPIPv6Domain.c files. But due to these changes, the Agent is not
> accepting GET and SET requests as it is not parsing as soon as it receives
> a packet.
>
> During the analysis, I get to know that the Agent does not perform any
> source based handling in case of SNMPv3 requests as it is already much
> secured. (Please correct me if I'm wrong)
>
> So can I have source address control for SNMPv1 and SNMPv2c alone?
>
>
>
>
> _______________________________________________
> Net-snmp-coders mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
> Hi,
>
> see the man pages of snmpd.conf and the section VACM in there.
>
>
> Mit freundlichen Grüßen,
>
> --
>
> [*] sys4 AG
>  https://sys4.de, +49 (89) 30 90 46 64
> Schleißheimer Straße 26/MG,80333 München
>
> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
> Aufsichtsratsvorsitzender: Florian Kirstein
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>


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

Re: Source Address based Configuration Control in SNMP Agent

[Michael S. <ms...@sy...>]

Am 15.12.18 um 15:11 schrieb prabu varadharajan:
> Dear All,
>
> As per my implementation, I would like to have only one Manager in my
> network who can configure my device, rest all can read the configuration.
> For example, even multiple NMS available in the network which can read the
> configuration(GET) where *only one NMS can write the configurations*(SET).
>
> This can be achieved by adding the following directive in snmpd.conf in
> case of SNMPv1 and SNMPv3,
>
> rwcommunity public 192.168.1.1
>
> But how can I achieve the same in case of SNMPv3? Please advise.
>
> If my Agent is configured in SNMPv3, the following directives will be
> available in the snmpd.conf file,
>
> createUser admin MD5 password AES password123
> rwuser admin priv
>
> I tried to do the source filtering whenever the agent receives a packet and
> able to achieve the same by updating the snmpUDPDomain.c and
> snmpUDPIPv6Domain.c files. But due to these changes, the Agent is not
> accepting GET and SET requests as it is not parsing as soon as it receives
> a packet.
>
> During the analysis, I get to know that the Agent does not perform any
> source based handling in case of SNMPv3 requests as it is already much
> secured. (Please correct me if I'm wrong)
>
> So can I have source address control for SNMPv1 and SNMPv2c alone?
>
>
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Hi,

see the man pages of snmpd.conf and the section VACM in there.


Mit freundlichen Grüßen,

-- 

[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein

Source Address based Configuration Control in SNMP Agent

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

Dear All,

As per my implementation, I would like to have only one Manager in my
network who can configure my device, rest all can read the configuration.
For example, even multiple NMS available in the network which can read the
configuration(GET) where *only one NMS can write the configurations*(SET).

This can be achieved by adding the following directive in snmpd.conf in
case of SNMPv1 and SNMPv3,

rwcommunity public 192.168.1.1

But how can I achieve the same in case of SNMPv3? Please advise.

If my Agent is configured in SNMPv3, the following directives will be
available in the snmpd.conf file,

createUser admin MD5 password AES password123
rwuser admin priv

I tried to do the source filtering whenever the agent receives a packet and
able to achieve the same by updating the snmpUDPDomain.c and
snmpUDPIPv6Domain.c files. But due to these changes, the Agent is not
accepting GET and SET requests as it is not parsing as soon as it receives
a packet.

During the analysis, I get to know that the Agent does not perform any
source based handling in case of SNMPv3 requests as it is already much
secured. (Please correct me if I'm wrong)

So can I have source address control for SNMPv1 and SNMPv2c alone?

-- 
With Best Regards,
Anandaprabu V <https://www.linkedin.com/in/anandaprabu-v-10867671/>
Cell : +91 9500650885 | Skype : prabuvaradharajan

IF-MIB::ifOperStatus

[Josef R. <jr...@re...>]

Hi,

I am trying to find, where is IF-MIB::ifOperStatus value taken from on Linux.
Can someone point me to the correct file?

I would like to find, why IF-MIB::ifOperStatus is set to UP for interface, that is down (e.g. ifdown eth0 -> snmpwalk -v2c -c public localhost .1.3.6.1.2.1.2.2.1.8 returns UP)

Regards

Josef

Re: List of RFCs supported by net-snmp version 5.7.3

[Venkateswarlu K. <ven...@gm...>]

Hi,

Thanks for your reply.

Yes, we want to advertise which RFCs we are supporting for net-snmp 5.7.3
for clients/customers.


The following RFCs i want to know which are supporting in net-snmp 5.7.3 or
not ?

RFC 2737: Entity MIB (Version 2)

RFC 2863: MIB (Interfaces Group)

RFC 3246: Expedited PHB

RFC 3411: Architecture for SNMP Management Frameworks

RFC 3412: Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)

RFC 3413: SNMP Applications

RFC 3414: User-based Security Model (USM) for Version 3 of the Simple
Network Management Protocol (SNMPv3)

RFC 3415: View-based Access Control Model

RFC 3416: V2 of SNMP Protocol Operations

RFC 3417: Transport Mappings for the Simple Network Management Protocol
(SNMP)

RFC 4502: Remote Monitoring Management Information Base Version 2

The Core, Distribution, and Access products shall support the following
network monitoring features:

a. Simple Network Management Protocol Version 3 (SNMPv3) IAW RFCs 3411,
3412, 3413, 3414, 3415, 3416, and 3417.

b. Remote Monitoring (RMON) IAW RFC 2819. The product shall minimally
support the following RFC 2819 groups: ethernet statistics, history
control, ethernet history, and alarm.

c. Coexistence between Version 1, Version 2, and Version 3 of the
Internet-standard Network Management Framework IAW RFC 3584.

d. The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP
User-based Security Model IAW RFC 3826.

By the way i am compiling the snmp mibs like below:

ifeq ($(strip ${BR2_PACKAGE_NETSNMP_SNMPV3}),y)
NETSNMP_CONFIG +=       --with-default-snmp-version="3" \
                        --with-mib-modules="snmpv3mibs mibII
utilities/execute" \
                        --with-out-mib-modules="ucd_snmp utilities
notification notification-log-mib target agent_mibs agentx disman/event-mib
disman/schedule host"
else
NETSNMP_CONFIG +=       --disable-md5 \
                        --disable-des \
                        --disable-privacy \
                        --with-default-snmp-version="2" \
                        --with-mib-modules="mibII/ipv6 utilities/execute" \
                        --with-out-mib-modules="snmpv3mibs ucd_snmp
utilities notification notification-log-mib target agent_mibs agentx
disman/event-mib disman/schedule host"
endif

If i want to support the above mentioned RFCs MIBs, i have to compile the
respective mibs for my agent? if yes, can you please tell me the procedure.


Thanks,

Venkateswarlu.K


On Mon, Nov 26, 2018 at 10:52 PM Wes Hardaker <
har...@us...> wrote:

> Venkateswarlu Konamki <ven...@gm...> writes:
>
> > Can someone tell me the list of RFCs supported by net-snmp 5.7.3
> > version ?
>
> We don't have a definitive list written out anywhere.  Generally
> speaking all the base RFCs, along with all the SNMPv3 RFCs are
> supported.  The agent supports a large number of MIB RFCs, but it
> depends on whether or not you compile in certain modules sometimes that
> are by default off.
>
> Can you be more specific on exactly what you need to know?  Why do you
> need a list of RFCs instead of a list of features you need?
>
> [many times companies like to advertise which RFCs they support as
> clients ask for it, and maybe this is one of those cases]
> --
> Wes Hardaker
> Please mail all replies to net...@li...
>

Re: List of RFCs supported by net-snmp version 5.7.3

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

Venkateswarlu Konamki <ven...@gm...> writes:

> Can someone tell me the list of RFCs supported by net-snmp 5.7.3
> version ?

We don't have a definitive list written out anywhere.  Generally
speaking all the base RFCs, along with all the SNMPv3 RFCs are
supported.  The agent supports a large number of MIB RFCs, but it
depends on whether or not you compile in certain modules sometimes that
are by default off.

Can you be more specific on exactly what you need to know?  Why do you
need a list of RFCs instead of a list of features you need?

[many times companies like to advertise which RFCs they support as
clients ask for it, and maybe this is one of those cases]
-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Is Netsnmp5.8 stable version

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

Madhusudhana R <mad...@in...> writes:

> Please let me know if Netsnmpv5.8  is Stable version or not.

Hi Madu,

Yes it is a "stable" release.  Note that any of our releases that don't
have "pre" or "RC" in the version string are considered "stable".

> I don’t see Long term support (LTS) in source-forge portal

However, the 5.8 branch is not a LTS branch, but is still stable (not
experimental).  Basically, our software release policy is simply that
some branches we commit to supporting and maintaining patches for longer
than other branches.  So the LTS branches are intentionally much longer
lived.

That being said, we tend to keep all branches alive far far longer than
we promise, including the non-LTS branches.

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

Is Netsnmp5.8 stable version

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

Hi Coders,

Please let me know if Netsnmpv5.8  is Stable version or not.
I don't see Long term support (LTS) in source-forge portal (where the code base is shared) and I am bit unsure if this is stable version or not. Please clarify.

Thanks in advance.

Regards,
Madhu

SNMP MIBS

[Александр Ф. <afo...@gm...>]

Good day.

Can you help me with one question?

I want to receive data on zfs file system(IOPS,read,write). I found the mib
file ,uploaded to the directory, and created disk pool. I'm trying to get
data,but i get the message "No Such Object","No data available".Maybe i
need some more components to work with this mib file? Are there standart
modules for working with the zfs file system?

I'm sorry for my bad english.

List of RFCs supported by net-snmp version 5.7.3

[Venkateswarlu K. <ven...@gm...>]

  Hi All,

Can someone tell me the list of RFCs supported by net-snmp 5.7.3 version ?

Thanks,
Venkat

List of RFCs supported by netsnmp version 5.7.3

[Venkateswarlu K. <ven...@gm...>]

Hi All,

Can someone tell me the list of RFCs supported by net-snmp 5.7.3 version ?

Thanks,
Venkat

Re: netsnmp5.8 compilation errors on windows (asprintf and vasprintf)

[Gisle V. <gv...@ya...>]

Madhusudhana R wrote:

> Hi Coders,
> 
> I am trying to compile netsnmp 5.8 on windows 7 platform using VS2013 framework.
> 
> I am getting compilation errors on asprintf and vasprintf usage as shown below
> 
> As per my analysis I don’t see VS2013 compiler provides support for asprintf and vasprintf. I observed they are replaced 
> for snprintf() and vsnprintf() functions in previous netsnmp v5.7.3. Can anyone help me how can I resolve this issue?
> 
> Error      32           error LNK2019: unresolved external symbol _vasprintf referenced in function _snmp_vlog          
> C:\ net-snmp-5.8\win32\encode_keychange\netsnmp.lib(snmp_logging.obj)          encode_keychange

You seems to link to the static Net-SNMP library.
And 'snmplib/asprintf.c' is missing from the Makefile somehow.

Maybe '-DHAVE_ASPRINTF' was added by a mistake?
Try using the NetSNMP.dll instead.

-- 
--gv

netsnmp5.8 compilation errors on windows (asprintf and vasprintf)

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

Hi Coders,

I am trying to compile netsnmp 5.8 on windows 7 platform using VS2013 framework.

I am getting compilation errors on asprintf and vasprintf usage as shown below
As per my analysis I don't see VS2013 compiler provides support for asprintf and vasprintf. I observed they are replaced for snprintf() and vsnprintf() functions in previous netsnmp v5.7.3. Can anyone help me how can I resolve this issue?

Error      32           error LNK2019: unresolved external symbol _vasprintf referenced in function _snmp_vlog          C:\ net-snmp-5.8\win32\encode_keychange\netsnmp.lib(snmp_logging.obj)          encode_keychange

Error      33           error LNK2019: unresolved external symbol _asprintf referenced in function _read_all_mibs      C:\ net-snmp-5.8\win32\encode_keychange\netsnmp.lib(parse.obj)           encode_keychange

Error      34           error LNK2001: unresolved external symbol _asprintf     C:\ net-snmp-5.8\win32\encode_keychange\netsnmp.lib(snmpIPv4BaseDomain.obj)               encode_keychange

Error      35           error LNK1120: 2 unresolved externals   C:\ net-snmp-5.8\win32\bin\debug\encode_keychange.exe                encode_keychange


Thanks in advance.

Regards,
Madhu

Re: EXTERNAL: Re: 5.7.3 | snmptrap not populating EngineBoots or EngineTime for snmp v3 traps

[Denis H. <den...@gm...>]

On Sat, Nov 10, 2018 at 01:04:38AM +0000, Roedersheimer, Drew A. wrote:
> Denis Hainsworth wrote:
> > 
> > Thanks Drew!  Yeah it seems fix  snmptrap which was my primary
> > concern.   
> > -denis
> 
> 
> Denis,
> 
> If you want this fixed in the net-snmp baseline code, I suggest you open an issue on the sourceforge page at: https://sourceforge.net/p/net-snmp/bugs/
> 
> If you create a bug report, I will add my patch as a possible solution.
> 

#2899 - snmptrap bug
#2900 - snmptrapd bug

-denis

RE: EXTERNAL: Re: 5.7.3 | snmptrap not populating EngineBoots or EngineTime for snmp v3 traps

[Roedersheimer, D. A. <Dre...@le...>]

Denis Hainsworth wrote:
> 
> Thanks Drew!  Yeah it seems fix  snmptrap which was my primary
> concern.   
> -denis


Denis,

If you want this fixed in the net-snmp baseline code, I suggest you open an issue on the sourceforge page at: https://sourceforge.net/p/net-snmp/bugs/

If you create a bug report, I will add my patch as a possible solution.



-Drew

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

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

I've applied my clientaddr parsing fix for IPv4 and IPv6, passing ":0" as
the default transport, and also modified the IPv6 address parser to handle
a bare IPv6 address (no brackets, no port).  With these changes, all of the
tests pass in their original form.

I'd like to add some more tests for specifying a port explicitly, after
which we can get rid of the complex code that tries to do this for the
limited v4 case, and make all 4 cases (v4 source address, v4 clientaddr, v6
source address, v6 clientaddr) the same, but I've run out of time for now.

  Bill

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

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

> On Nov 7, 2018, at 1:27 AM, Bart Van Assche <bva...@ac...> wrote:
> 
>> On 11/6/18 12:31 PM, Bill Fenner wrote:
>> Playing with this in V5-8-patches, I see it broke my fix for using clientaddr to specify the source address for traps:
>> netsnmp_sockaddr_in: addr 0xffd5e824, inpeername "127.0.0.1", default_target ":0"
>> netsnmp_sockaddr_in: addr 0xffd5e824, inpeername ":0", default_target "[NIL]"
>> netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:161 <http://0.0.0.0:161> }
>> netsnmp_sockaddr_in: hostname (resolved okay)
>> netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 <http://127.0.0.1:161> }
>> In the previous implementation, specifying a default_target of ":0" would set the port number to zero, meaning, let the kernel decide.  Now, it appears to mean, use the SNMP default.  This causes the bind() to fail, of course, since binding to 127.0.0.1:0 <http://127.0.0.1:0> would work fine, but binding to 127.0.0.1:161 <http://127.0.0.1:161> conflicts with the actual snmpd port.
>> netsnmp_udpbase: open remote UDP: [172.25.24.62]:5716->[0.0.0.0]:0
>> netsnmp_udpbase: binding socket: 8 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
>> netsnmp_udpbase: failed to bind for clientaddr: 13 Permission denied
>> snmpd: netsnmp_create_notification_session:
>> /tmp/snmp-test-T180trap2sinkclientaddr_simple-7030/snmpd.conf: line 8: Error: cannot create sink: udp:172.25.24.62:5716 <http://172.25.24.62:5716>
>> I've committed my tests for trap2sink, trapsess, and using "-s" with trapsess.  None of the v6 versions work, but the v4 trapsess versions work, after fixing netsnmp_udpipv4base_transport_with_source() to use the "bind_addr" variable.  I believe that fixing the parsing of ":0" to return a zero port like it did before would fix trap2sink.  I haven't looked at what's wrong with v6 yet.
>> (The confusing code in netsnmp_udpipv4base_transport() around "have_port" and "uses_port", including the introduction of NETSNMP_DS_LIB_CLIENT_ADDR_USES_PORT, is probably completely working around this same bug of setting the port when it doesn't need to be set, and could be eliminated altogether if that bug is fixed.)
> 
> Oops, that's something I was not aware of. Can you check that whether the changes I checked in earlier today fix this regression? Are there any other regressions than this one that you are aware of?

5.8 was released with regressions in this area already, so the regressions that are present in this branch are not necessarily due to your changes. The T18* tests (without the change to specify the port explicitly) should all pass (and do in the 5-7-patches branch).

I think one thing for v6 is that it needs to be able to parse a bare IP address without port or brackets (for clientaddr purposes).


The T18* tests should probably be improved to prohibit receiving traps sourced from port 161 or 162, in case someone runs the tests as root. I will look at making this change.

  Bill

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

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

On 11/6/18 12:31 PM, Bill Fenner wrote:
> Playing with this in V5-8-patches, I see it broke my fix for using 
> clientaddr to specify the source address for traps:
> 
> netsnmp_sockaddr_in: addr 0xffd5e824, inpeername "127.0.0.1", 
> default_target ":0"
> netsnmp_sockaddr_in: addr 0xffd5e824, inpeername ":0", default_target 
> "[NIL]"
> netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:161 <http://0.0.0.0:161> }
> netsnmp_sockaddr_in: hostname (resolved okay)
> netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 
> <http://127.0.0.1:161> }
> 
> In the previous implementation, specifying a default_target of ":0" 
> would set the port number to zero, meaning, let the kernel decide.  Now, 
> it appears to mean, use the SNMP default.  This causes the bind() to 
> fail, of course, since binding to 127.0.0.1:0 <http://127.0.0.1:0> would 
> work fine, but binding to 127.0.0.1:161 <http://127.0.0.1:161> conflicts 
> with the actual snmpd port.
> 
> netsnmp_udpbase: open remote UDP: [172.25.24.62]:5716->[0.0.0.0]:0
> netsnmp_udpbase: binding socket: 8 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
> netsnmp_udpbase: failed to bind for clientaddr: 13 Permission denied
> snmpd: netsnmp_create_notification_session:
> /tmp/snmp-test-T180trap2sinkclientaddr_simple-7030/snmpd.conf: line 8: 
> Error: cannot create sink: udp:172.25.24.62:5716 <http://172.25.24.62:5716>
> 
> I've committed my tests for trap2sink, trapsess, and using "-s" with 
> trapsess.  None of the v6 versions work, but the v4 trapsess versions 
> work, after fixing netsnmp_udpipv4base_transport_with_source() to use 
> the "bind_addr" variable.  I believe that fixing the parsing of ":0" to 
> return a zero port like it did before would fix trap2sink.  I haven't 
> looked at what's wrong with v6 yet.
> 
> (The confusing code in netsnmp_udpipv4base_transport() around 
> "have_port" and "uses_port", including the introduction 
> of NETSNMP_DS_LIB_CLIENT_ADDR_USES_PORT, is probably completely working 
> around this same bug of setting the port when it doesn't need to be set, 
> and could be eliminated altogether if that bug is fixed.)

Oops, that's something I was not aware of. Can you check that whether 
the changes I checked in earlier today fix this regression? Are there 
any other regressions than this one that you are aware of?

Thanks,

Bart.

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

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

On 11/6/18 8:03 AM, Bill Fenner wrote:
> My main question is, what's the advantage of storing the IPv4/IPv6 
> address as a string and a port number, instead of as a sockaddr_*?  
> I.e., why use netsnmp_ep_str?

Parsing endpoint addresses happens in two phases: first parsing the 
endpoint strings and next the conversion into a sockaddr_* structure. 
The code for the first conversion is shared by the IPv4 and IPv6 
transports while the code for the second conversion is transport 
specific. Hence two data structures, netsnmp_ep_str and netsnmp_ep.

> Is the API change here ok?  Are we assuming that nobody ever calls 
> netsnmp_foo_transport() directly?

My own preference is to make the entire transport API internal to 
libsnmp and not to allow any direct calls to any transport code from 
outside libsnmp. That would make it much easier to maintain and refactor 
that code.

> Should there be an #ifdef in patch 5 to make the interface name 
> optional, both in the struct and the parser, for platforms that don't 
> support it?  Is it better to return a parse error on the address that 
> includes interface name, or a "failed to open socket" without much more 
> information?

That case should already be handled by the following code in 
netsnmp_bindtodevice():

     if (!iface || iface[0] == '\0')
         return 0;
#ifdef HAVE_SO_BINDTODEVICE
     [ ... ]
#else
     errno = EINVAL;
     return -1;
#endif

> 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.

Bart.

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

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

I screwed up the v6 tests a little, and just pushed some fixes to it.  The
current status is: the 4 tests that are in V5-7-patches all pass
(trap2sink, v6 trap2sink, trapsess, v6 trapsess).  I applied the same
clientaddr port zeroing to v6 as v4 already has in V5-7-patches to get the
v6 trapsink version to pass.

Since the code is all different in 5.8, the fixes don't apply.  The v4
trapsink case and all of the v6 cases (including the added case for "-s"
with trapsess) fail.  The two v4 trapsess cases succeed.  All of the
failures in 5.8 are regressions from V5-7-patches.  (They were regressions
before your changes here, but your changes broke my fix that Sam tried in
https://sourceforge.net/p/net-snmp/bugs/2888/ )

  Bill


On Tue, Nov 6, 2018 at 3:31 PM Bill Fenner <fe...@us...>
wrote:

> Playing with this in V5-8-patches, I see it broke my fix for using
> clientaddr to specify the source address for traps:
>
> netsnmp_sockaddr_in: addr 0xffd5e824, inpeername "127.0.0.1",
> default_target ":0"
> netsnmp_sockaddr_in: addr 0xffd5e824, inpeername ":0", default_target
> "[NIL]"
> netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:161 }
> netsnmp_sockaddr_in: hostname (resolved okay)
> netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 }
>
> In the previous implementation, specifying a default_target of ":0" would
> set the port number to zero, meaning, let the kernel decide.  Now, it
> appears to mean, use the SNMP default.  This causes the bind() to fail, of
> course, since binding to 127.0.0.1:0 would work fine, but binding to
> 127.0.0.1:161 conflicts with the actual snmpd port.
>
> netsnmp_udpbase: open remote UDP: [172.25.24.62]:5716->[0.0.0.0]:0
> netsnmp_udpbase: binding socket: 8 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
> netsnmp_udpbase: failed to bind for clientaddr: 13 Permission denied
> snmpd: netsnmp_create_notification_session:
> /tmp/snmp-test-T180trap2sinkclientaddr_simple-7030/snmpd.conf: line 8:
> Error: cannot create sink: udp:172.25.24.62:5716
>
> I've committed my tests for trap2sink, trapsess, and using "-s" with
> trapsess.  None of the v6 versions work, but the v4 trapsess versions work,
> after fixing netsnmp_udpipv4base_transport_with_source() to use the
> "bind_addr" variable.  I believe that fixing the parsing of ":0" to return
> a zero port like it did before would fix trap2sink.  I haven't looked at
> what's wrong with v6 yet.
>
> (The confusing code in netsnmp_udpipv4base_transport() around "have_port"
> and "uses_port", including the introduction
> of NETSNMP_DS_LIB_CLIENT_ADDR_USES_PORT, is probably completely working
> around this same bug of setting the port when it doesn't need to be set,
> and could be eliminated altogether if that bug is fixed.)
>
>   Bill
>
>
> On Tue, Nov 6, 2018 at 11:03 AM Bill Fenner <fe...@us...>
> wrote:
>
>> Hi Bart,
>>
>> My main question is, what's the advantage of storing the IPv4/IPv6
>> address as a string and a port number, instead of as a sockaddr_*?  I.e.,
>> why use netsnmp_ep_str?
>>
>> Is the API change here ok?  Are we assuming that nobody ever calls
>> netsnmp_foo_transport() directly?
>>
>> Should there be an #ifdef in patch 5 to make the interface name optional,
>> both in the struct and the parser, for platforms that don't support it?  Is
>> it better to return a parse error on the address that includes interface
>> name, or a "failed to open socket" without much more information?
>>
>> 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.
>>
>> I don't have a strong opinion about which this code should go in.
>>
>>   Bill
>>
>>
>> On Sun, Oct 28, 2018 at 5:19 PM Bart Van Assche <bva...@ac...>
>> 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
>>>
>>> The reason I'm posting this patch series on the Net-SNMP mailing list is
>>> to
>>> gather feedback about this patch series. Does everyone agree with the
>>> code
>>> changes in this patch series? If so, on which branch(es) should these
>>> patches
>>> be applied? Master only or v5.8 and master?
>>>
>>> See also:
>>> * Add SO_BINDTODEVICE support
>>>   (https://sourceforge.net/p/net-snmp/patches/1296/).
>>> * Add Linux VRF support (
>>> https://sourceforge.net/p/net-snmp/patches/1376/).
>>>
>>> Thanks,
>>>
>>> Bart.
>>>
>>> Bart Van Assche (6):
>>>   libsnmp/transports: Introduce netsnmp_parse_ep_str()
>>>   libsnmp/transports: Introduce netsnmp_sockaddr_in3() and
>>>     netsnmp_sockaddr_in6_3()
>>>   libsnmp/transports: Change multiple sockaddr_in* arguments into
>>>     netsnmp_ep
>>>   configure: Add a test for SO_BINDTODEVICE
>>>   libsnmp/transports: Add support for interface binding
>>>   testing/fulltests/unit-tests: Add netsnmp_parse_ep_str() unit test
>>>
>>>  configure                                     |  34 +++
>>>  configure.d/config_os_misc4                   |  15 ++
>>>  include/net-snmp/library/snmpDTLSUDPDomain.h  |   4 +-
>>>  include/net-snmp/library/snmpIPBaseDomain.h   |  36 +++
>>>  include/net-snmp/library/snmpIPv4BaseDomain.h |   7 +
>>>  include/net-snmp/library/snmpIPv6BaseDomain.h |   5 +
>>>  include/net-snmp/library/snmpTCPDomain.h      |   4 +-
>>>  include/net-snmp/library/snmpTCPIPv6Domain.h  |   4 +-
>>>  include/net-snmp/library/snmpUDPDomain.h      |   8 +-
>>>  .../net-snmp/library/snmpUDPIPv4BaseDomain.h  |  12 +-
>>>  include/net-snmp/library/snmpUDPIPv6Domain.h  |  11 +-
>>>  .../net-snmp/library/snmpUDPsharedDomain.h    |   6 +-
>>>  include/net-snmp/net-snmp-config.h.in         |   3 +
>>>  snmplib/transports/snmpDTLSUDPDomain.c        |  36 +--
>>>  snmplib/transports/snmpIPBaseDomain.c         | 114 +++++++++
>>>  snmplib/transports/snmpIPv4BaseDomain.c       | 118 +++------
>>>  snmplib/transports/snmpIPv6BaseDomain.c       | 238 ++++--------------
>>>  snmplib/transports/snmpTCPDomain.c            |  24 +-
>>>  snmplib/transports/snmpTCPIPv6Domain.c        |  23 +-
>>>  snmplib/transports/snmpUDPDomain.c            |  22 +-
>>>  snmplib/transports/snmpUDPIPv4BaseDomain.c    |  58 +++--
>>>  snmplib/transports/snmpUDPIPv6Domain.c        |  70 +++---
>>>  snmplib/transports/snmpUDPsharedDomain.c      |  90 ++++---
>>>  testing/fulltests/support/clib_build          |   1 +
>>>  .../T022netsnmp_parse_ep_str_clib.c           |  55 ++++
>>>  win32/libsnmp/Makefile.in                     |   1 +
>>>  win32/libsnmp_dll/Makefile.in                 |   1 +
>>>  27 files changed, 561 insertions(+), 439 deletions(-)
>>>  create mode 100644 include/net-snmp/library/snmpIPBaseDomain.h
>>>  create mode 100644 snmplib/transports/snmpIPBaseDomain.c
>>>  create mode 100644
>>> testing/fulltests/unit-tests/T022netsnmp_parse_ep_str_clib.c
>>>
>>> --
>>> 2.19.1
>>>
>>>

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

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

Playing with this in V5-8-patches, I see it broke my fix for using
clientaddr to specify the source address for traps:

netsnmp_sockaddr_in: addr 0xffd5e824, inpeername "127.0.0.1",
default_target ":0"
netsnmp_sockaddr_in: addr 0xffd5e824, inpeername ":0", default_target
"[NIL]"
netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:161 }
netsnmp_sockaddr_in: hostname (resolved okay)
netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 }

In the previous implementation, specifying a default_target of ":0" would
set the port number to zero, meaning, let the kernel decide.  Now, it
appears to mean, use the SNMP default.  This causes the bind() to fail, of
course, since binding to 127.0.0.1:0 would work fine, but binding to
127.0.0.1:161 conflicts with the actual snmpd port.

netsnmp_udpbase: open remote UDP: [172.25.24.62]:5716->[0.0.0.0]:0
netsnmp_udpbase: binding socket: 8 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
netsnmp_udpbase: failed to bind for clientaddr: 13 Permission denied
snmpd: netsnmp_create_notification_session:
/tmp/snmp-test-T180trap2sinkclientaddr_simple-7030/snmpd.conf: line 8:
Error: cannot create sink: udp:172.25.24.62:5716

I've committed my tests for trap2sink, trapsess, and using "-s" with
trapsess.  None of the v6 versions work, but the v4 trapsess versions work,
after fixing netsnmp_udpipv4base_transport_with_source() to use the
"bind_addr" variable.  I believe that fixing the parsing of ":0" to return
a zero port like it did before would fix trap2sink.  I haven't looked at
what's wrong with v6 yet.

(The confusing code in netsnmp_udpipv4base_transport() around "have_port"
and "uses_port", including the introduction
of NETSNMP_DS_LIB_CLIENT_ADDR_USES_PORT, is probably completely working
around this same bug of setting the port when it doesn't need to be set,
and could be eliminated altogether if that bug is fixed.)

  Bill


On Tue, Nov 6, 2018 at 11:03 AM Bill Fenner <fe...@us...>
wrote:

> Hi Bart,
>
> My main question is, what's the advantage of storing the IPv4/IPv6 address
> as a string and a port number, instead of as a sockaddr_*?  I.e., why use
> netsnmp_ep_str?
>
> Is the API change here ok?  Are we assuming that nobody ever calls
> netsnmp_foo_transport() directly?
>
> Should there be an #ifdef in patch 5 to make the interface name optional,
> both in the struct and the parser, for platforms that don't support it?  Is
> it better to return a parse error on the address that includes interface
> name, or a "failed to open socket" without much more information?
>
> 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.
>
> I don't have a strong opinion about which this code should go in.
>
>   Bill
>
>
> On Sun, Oct 28, 2018 at 5:19 PM Bart Van Assche <bva...@ac...>
> 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
>>
>> The reason I'm posting this patch series on the Net-SNMP mailing list is
>> to
>> gather feedback about this patch series. Does everyone agree with the code
>> changes in this patch series? If so, on which branch(es) should these
>> patches
>> be applied? Master only or v5.8 and master?
>>
>> See also:
>> * Add SO_BINDTODEVICE support
>>   (https://sourceforge.net/p/net-snmp/patches/1296/).
>> * Add Linux VRF support (https://sourceforge.net/p/net-snmp/patches/1376/
>> ).
>>
>> Thanks,
>>
>> Bart.
>>
>> Bart Van Assche (6):
>>   libsnmp/transports: Introduce netsnmp_parse_ep_str()
>>   libsnmp/transports: Introduce netsnmp_sockaddr_in3() and
>>     netsnmp_sockaddr_in6_3()
>>   libsnmp/transports: Change multiple sockaddr_in* arguments into
>>     netsnmp_ep
>>   configure: Add a test for SO_BINDTODEVICE
>>   libsnmp/transports: Add support for interface binding
>>   testing/fulltests/unit-tests: Add netsnmp_parse_ep_str() unit test
>>
>>  configure                                     |  34 +++
>>  configure.d/config_os_misc4                   |  15 ++
>>  include/net-snmp/library/snmpDTLSUDPDomain.h  |   4 +-
>>  include/net-snmp/library/snmpIPBaseDomain.h   |  36 +++
>>  include/net-snmp/library/snmpIPv4BaseDomain.h |   7 +
>>  include/net-snmp/library/snmpIPv6BaseDomain.h |   5 +
>>  include/net-snmp/library/snmpTCPDomain.h      |   4 +-
>>  include/net-snmp/library/snmpTCPIPv6Domain.h  |   4 +-
>>  include/net-snmp/library/snmpUDPDomain.h      |   8 +-
>>  .../net-snmp/library/snmpUDPIPv4BaseDomain.h  |  12 +-
>>  include/net-snmp/library/snmpUDPIPv6Domain.h  |  11 +-
>>  .../net-snmp/library/snmpUDPsharedDomain.h    |   6 +-
>>  include/net-snmp/net-snmp-config.h.in         |   3 +
>>  snmplib/transports/snmpDTLSUDPDomain.c        |  36 +--
>>  snmplib/transports/snmpIPBaseDomain.c         | 114 +++++++++
>>  snmplib/transports/snmpIPv4BaseDomain.c       | 118 +++------
>>  snmplib/transports/snmpIPv6BaseDomain.c       | 238 ++++--------------
>>  snmplib/transports/snmpTCPDomain.c            |  24 +-
>>  snmplib/transports/snmpTCPIPv6Domain.c        |  23 +-
>>  snmplib/transports/snmpUDPDomain.c            |  22 +-
>>  snmplib/transports/snmpUDPIPv4BaseDomain.c    |  58 +++--
>>  snmplib/transports/snmpUDPIPv6Domain.c        |  70 +++---
>>  snmplib/transports/snmpUDPsharedDomain.c      |  90 ++++---
>>  testing/fulltests/support/clib_build          |   1 +
>>  .../T022netsnmp_parse_ep_str_clib.c           |  55 ++++
>>  win32/libsnmp/Makefile.in                     |   1 +
>>  win32/libsnmp_dll/Makefile.in                 |   1 +
>>  27 files changed, 561 insertions(+), 439 deletions(-)
>>  create mode 100644 include/net-snmp/library/snmpIPBaseDomain.h
>>  create mode 100644 snmplib/transports/snmpIPBaseDomain.c
>>  create mode 100644
>> testing/fulltests/unit-tests/T022netsnmp_parse_ep_str_clib.c
>>
>> --
>> 2.19.1
>>
>>