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

Re: oldEngineID format in snmpd.conf

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

On Wed, Jul 20, 2022 at 2:46 AM Feroz <fer...@gm...> wrote:

> What I configured in snmpd.conf file
>
> *engineID  8000b85c03d0672649a01e*
>

This configured net-snmp to use the string " 8000b85c03d0672649a01e" to
generate an engineID.

If you want to configure the engine-id with a hex string, please use the
"exactEngineID" configuration.  A sample usage:

exactEngineID 0xf5717f06fdc6db4a4600

  Bill

Re: oldEngineID format in snmpd.conf

[Feroz <fer...@gm...>]

What I configured in snmpd.conf file

*engineID  8000b85c03d0672649a01e*

NetSNMP converted the above engineID in to equivalent Hex value for each
character, i.e (8000b85c03d0672649a01e => 38 30 30 30 62 38 35 63 30 33 64
30 36 37 32 36 34 39 61 30 31 65) with some prefix *0x80001f8804*

*snippet:*
usmUser 1 3 0x80001f880438303030623835633033643036373236343961303165
"testv3user" "testv3user" NULL .1.3.6.1.6.3.10.1.1.2
0x055a6d2afcff5cb7a22c3a9c61b55c08 .1.3.6.1.6.3.10.1.2.4
0x055a6d2afcff5cb7a22c3a9c61b55c08 ""
engineBoots 8
*oldEngineID 0x80001f880438303030623835633033643036373236343961303165*


when I do  snpwalk with "-e  8000b85c03d0672649a01e" walk failed.
Where as snmpwalk works fine with
(-e 0x80001f880438303030623835633033643036373236343961303165)
I was expecting snmpwalk to work with "-e  8000b85c03d0672649a01e", this is
the engineId that I configured in snmpd.conf file.

On Tue, Jul 19, 2022 at 7:38 PM Wes Hardaker via Net-snmp-coders <
net...@li...> wrote:

> Abhishek Singh <abh...@gm...> writes:
>
> > I have a question on the format how oldEngineID is stored in snmpd.conf.
> > After configuring an engine ID, I observed the oldEngineID in snmpd.conf
> saved
> > as
> > engineBoots 1
> > oldEngineID 0x80001f880438303030623835633033653030373162633735333532
> >
> > The question is why the oldEngineID is stored in ASCII format when
> engine-id
> > input is actually Hex.
>
> The oldEngineID basically stores what was used in the last run, for if
> the engineID changes (in the current run) then boots needs to be reset.
>
> I'm not sure I understand the ascii question -- how are you setting the
> engineID?  If you're using a "string", the encode engineid still has
> some leading binary information to indicate it was set as a string.  IE,
> the engineID consists of more than just the string itself (per the
> SNMPv3 RFCs).
>
> --
> Wes Hardaker
> Please mail all replies to net...@li...
>
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>


-- 
Regards,
Feroz Ahmed

Re: oldEngineID format in snmpd.conf

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

Abhishek Singh <abh...@gm...> writes:

> I have a question on the format how oldEngineID is stored in snmpd.conf.
> After configuring an engine ID, I observed the oldEngineID in snmpd.conf saved
> as
> engineBoots 1
> oldEngineID 0x80001f880438303030623835633033653030373162633735333532
> 
> The question is why the oldEngineID is stored in ASCII format when engine-id
> input is actually Hex. 

The oldEngineID basically stores what was used in the last run, for if
the engineID changes (in the current run) then boots needs to be reset.

I'm not sure I understand the ascii question -- how are you setting the
engineID?  If you're using a "string", the encode engineid still has
some leading binary information to indicate it was set as a string.  IE,
the engineID consists of more than just the string itself (per the
SNMPv3 RFCs).

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

Re: Net-SNMP 5.9.3 published

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

Craig Small <csmall@dropbear.xyz> writes:

> Debian net-snmp packages 5.9.3-1 have also been built and uploaded.

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

Re: Net-SNMP 5.9.3 published

[Craig S. <cs...@dr...>]

On Thu, 14 Jul 2022 at 07:42, Wes Hardaker via Net-snmp-coders <
net...@li...> wrote:

>
> So a 5.9.3 release has now been pushed to:
>
Debian net-snmp packages 5.9.3-1 have also been built and uploaded.
No major issues, I'm hoping to reduce some of the patches I'm carrying if
possible but that's work for another day.

 - Craig

oldEngineID format in snmpd.conf

[Abhishek S. <abh...@gm...>]

Hello,

I have a question on the format how oldEngineID is stored in snmpd.conf.
After configuring an engine ID, I observed the oldEngineID in snmpd.conf
saved as

*engineBoots 1oldEngineID
0x80001f880438303030623835633033653030373162633735333532*

The question is why the oldEngineID is stored in ASCII format when
engine-id input is actually Hex.

Thank You in advance,
Abhishek S

Re: snmpv3 poll

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

Hi Paban,

This means that your manager and your agent are not using the same
algorithm for short-key extension.  There are two different algorithms that
are in use to extend the output of a short hash function (like SHA) for use
with longer encryption keys (like AES192).

When you run into this situation, the best way to handle it is to use a
hash function that has a long enough output so that it does not need to be
extended in order to input to the encryption method.  Unsurprisingly, these
combinations are exactly the ones that work in your table.

Alternately, you can try the "other" extension mechanism, which net-snmp
identifies by appending a "C" to the encryption mechanism, e.g., AES192C or
AES256C.  I have no experience with this, I've only seen the code.

  Bill


On Wed, Jul 13, 2022 at 10:29 AM Paban Agarwalla <pab...@gm...>
wrote:

> Hi,
>
> We are using snmpv3 on our device.
>
> when we configure v3 users. Some of the algorithm combinations failed.
>
> Please find the attached table.
>
> Regards
> Paban
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>

Re: snmpv3 poll

[Craig S. <cs...@dr...>]

On Thu, 14 Jul 2022 at 00:29, Paban Agarwalla <pab...@gm...>
wrote:

> when we configure v3 users. Some of the algorithm combinations failed.
>
That's an odd result.  It's like the authentication key length is having an
effect on the authentication key length you can use. If the auth key is
smaller than the privacy key, you get a failure.

RFC3826, which describes AES-128 for SNMP, says anything that has 128bits
or more for authentication will work with it and anything in RFC3414
(SHA-95 MD5-96) satisfy that.

Assuming they're using the Blumenthal extensions for AES-192 and AES-256, I
wonder if they're getting the rules around privacy key lengths and
authentication key lengths confused? For example the draft standard says "192
bits (24 octets) for AES-192" which would mean (if you thought it was the
auth key) that the top-center one should fail, but they're talking about
the privacy key here (section 3.2.1).

Another thought, are you using the same key for your privacy and
authentication?

 - Craig

Net-SNMP 5.9.3 published

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

So a 5.9.3 release has now been pushed to:

https://sourceforge.net/projects/net-snmp/files/net-snmp/5.9.3/

This fixes the last minute bug with .so library naming in 5.9.2.

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

Re: snmpv3 poll

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

Paban Agarwalla <pab...@gm...> writes:

> when we configure v3 users. Some of the algorithm combinations failed.

What is the device you're using?  Certainly it looks like a not-complete
interchangeability table.  Net-SNMP has demonstrated interchangeability
with many other implementations, but I don't know about every algorithm
combination.  Interesting results.
-- 
Wes Hardaker
Please mail all replies to net...@li...

snmpv3 poll

[Paban A. <pab...@gm...>]

Hi,

We are using snmpv3 on our device.

when we configure v3 users. Some of the algorithm combinations failed.

Please find the attached table.

Regards
Paban

Net-SNMP 5.9.3.rc1 published

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

To fix the discovered shared library versioning issue in 5.9.2,
5.9.3.rc1 has been published and is here:

https://sourceforge.net/projects/net-snmp/files/net-snmp/5.9.3-pre-releases/

Please give it a whirl, with the goal of proper 5.9.3 being published
next week.

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

Re: publishing 5.9.3 immediately

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

Craig Small <csmall@dropbear.xyz> writes:

> The trapd linking to the agent library (https://github.com/net-snmp/net-snmp/issues/434)
> probably needs some thought about the best way to do it. I'm not even sure why the basic
> compile works and Debian one doesn't, but it's probably GCC rightly finding an issue. Yes, one
> library assuming another is loaded to get to its functions is bad, but the fix probably needs
> some thought.
> 
> The MySQL include problems, I'm not sure why those other files were included. Maybe they were
> needed in other setups?

I agree we should fix these problems, but not in the 5.9.3 timeframe as
they're bigger fixes and 5.9.3 should get out the door asap.
-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: publishing 5.9.3 immediately

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

On Wed, Jul 06, 2022 at 12:27:36PM +1000, Craig Small wrote:
> On Wed, 6 Jul 2022 at 01:54, Bart Van Assche <bva...@ac...> wrote:
> 
> > How about also fixing the other two issues reported during the last 24
> > hours by Craig before announcing 5.9.3.rc1?
> >
> While I am always happy to have fewer patches in the Debian source (and I'm
> going to try to get some more into the upstream) the libcurrent issue is
> one that everyone can say (now) is wrong and there is a clear fix.
> 
> The trapd linking to the agent library (
> https://github.com/net-snmp/net-snmp/issues/434) probably needs some
> thought about the best way to do it. I'm not even sure why the basic
> compile works and Debian one doesn't, but it's probably GCC rightly finding
> an issue. Yes, one library assuming another is loaded to get to its
> functions is bad, but the fix probably needs some thought.

I think our libs need some overhaul.

If you want to compile an agentx subagent you have get link time dependencies
to libcrypto even though there is no support for encrypted communications
over agentx.

If you agentx subagent is old and uses the util_funcs helpers then you get
link time dependencies on everything snmpd depends on.

The small fix to the second issue would be to add
config_belongs_in(agent_module) in util_funcs/header_simple_table.h and
util_funcs/header_generic.h, effectivley moving them from libnetsnmpmibs to
libnetsnmpagent.

Fixing the first issue is more intricate as libcrypto is pulled in by the
snmpv3 support code.

/MF

Re: publishing 5.9.3 immediately

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

On Tue, Jul 05, 2022 at 08:28:54AM -0700, Wes Hardaker via Net-snmp-coders wrote:
> 
> So this issues:
> 
> https://github.com/net-snmp/net-snmp/issues/432
> 
> Likely warrants an immediate 5.9.3 with only the change to libcurrent in
> Makefile.top.

+1

> I'll try to get 5.9.3.rc1 out the door today to address this.

Regarding the other issues I agree that they can wait.

> -- 
> Wes Hardaker
> Please mail all replies to net...@li...
> 
> 
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: publishing 5.9.3 immediately

[Craig S. <cs...@dr...>]

On Wed, 6 Jul 2022 at 01:54, Bart Van Assche <bva...@ac...> wrote:

> How about also fixing the other two issues reported during the last 24
> hours by Craig before announcing 5.9.3.rc1?
>
While I am always happy to have fewer patches in the Debian source (and I'm
going to try to get some more into the upstream) the libcurrent issue is
one that everyone can say (now) is wrong and there is a clear fix.

The trapd linking to the agent library (
https://github.com/net-snmp/net-snmp/issues/434) probably needs some
thought about the best way to do it. I'm not even sure why the basic
compile works and Debian one doesn't, but it's probably GCC rightly finding
an issue. Yes, one library assuming another is loaded to get to its
functions is bad, but the fix probably needs some thought.

The MySQL include problems, I'm not sure why those other files were
included. Maybe they were needed in other setups?

 - Craig

Re: Net-SNMP 5.9.2 published

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

On 7/5/22 11:01, Wes Hardaker wrote:
> However, the 5.9 branch and the main branch have a *lot* of conflicts to
> resolve.  The process of always merging patches to main frequently to
> avoid this has fallen away, and the branches are now fairly divergent
> which is going to be a problem to solve first -- how do we get main in
> line with the important changes in the V5-9-patches branch?

The number of patches that is on the v5.9 branch but not on the master 
branch should be small. The only patches for which I encountered merge 
conflicts recently are the patches that update the change log and the 
version numbers. Am I perhaps missing something?

Thanks,

Bart.

Re: Net-SNMP 5.9.2 published

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

Bart Van Assche <bva...@ac...> writes:

> +1 for releasing the next version from the master branch. That would
> make Net-SNMP easier to maintain since it would reduce the number of 
> branches to maintain from two to one.

Agreed, though typically we'd fork after that point with a patches
branch.  We should probably revisit that whole discussion too though.

However, the 5.9 branch and the main branch have a *lot* of conflicts to
resolve.  The process of always merging patches to main frequently to
avoid this has fallen away, and the branches are now fairly divergent
which is going to be a problem to solve first -- how do we get main in
line with the important changes in the V5-9-patches branch?
-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Net-SNMP 5.9.2 published

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

On 6/30/22 19:23, Wes Hardaker via Net-snmp-coders wrote:
> I'm thinking we should look toward a main-branch release next (5.10).
> Opinions welcome.

+1 for releasing the next version from the master branch. That would 
make Net-SNMP easier to maintain since it would reduce the number of 
branches to maintain from two to one.

Thanks,

Bart.

Re: publishing 5.9.3 immediately

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

On 7/5/22 08:28, Wes Hardaker via Net-snmp-coders wrote:
> 
> So this issues:
> 
> https://github.com/net-snmp/net-snmp/issues/432
> 
> Likely warrants an immediate 5.9.3 with only the change to libcurrent in
> Makefile.top.
> 
> I'll try to get 5.9.3.rc1 out the door today to address this.

How about also fixing the other two issues reported during the last 24 
hours by Craig before announcing 5.9.3.rc1?

Thanks,

Bart.

publishing 5.9.3 immediately

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

So this issues:

https://github.com/net-snmp/net-snmp/issues/432

Likely warrants an immediate 5.9.3 with only the change to libcurrent in
Makefile.top.

I'll try to get 5.9.3.rc1 out the door today to address this.

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

Net-SNMP 5.9.2 published

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

I'll send a full announcement early next week, but Net-SNMP 5.9.2 is
published and is at:

https://sourceforge.net/projects/net-snmp/files/net-snmp/5.9.2/

I'm thinking we should look toward a main-branch release next (5.10).
Opinions welcome.

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

net-snmp-5.9.2.rc2 published for testing

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

There have only been a few changes since rc1, but enough that it
warrants another rc2.  Please propose no changes at this point unless
there is a critical issue.

https://sourceforge.net/projects/net-snmp/files/net-snmp/5.9.2-pre-releases/

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

Re: Securing snmpd.conf files

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

Craig Small <csmall@dropbear.xyz> writes:

>     Is there a way to encrypt passwords in the snmpd.conf file? Currently, when we open
>     snmpd.conf file we can look at passwords in plaintext format, is there a way to
>     store those passwords in encrypted form. Does net-snmp support any encryption/
>     decryption of passwords while reading from snmpd.conf?
> 
> The snmpusm manpage describes a way of making SNMP v3 users. 
> The passwords are, I believe, stored as MD5 HMAC and not cleartext.

Good answer and thanks for noting this.

Even more importantly: they're not only stored as a MAC, but also stored
in a way that is isolated to just that machine and localized with an
engineid.

Specifically, the snmpd.conf manual page about the createUser line says:

     This directive  should  be  placed  into  the  /var/net-snmp/sn‐
     mpd.conf file instead of the other normal locations.  The reason
     is that the information is read from the file and then the  line
     is  removed  (eliminating the storage of the master password for
     that user) and replaced with the key that is  derived  from  it.
     This  key is a localized key, so that if it is stolen it can not
     be used to access other agents.  If the password is stolen, how‐
     ever, it can be.

Thus the createUser line should *never* be put in a global config file
that is not where the agent stores it's data in the first place.  The
manual page also talks about how to use the net-snmp-config tool to help
with this:

     Instead  of  figuring out how to use this directive and where to
     put it  (see  below),  just  run  "net-snmp-config  --create-sn‐
     mpv3-user"  instead,  which  will  add one of these lines to the
     right place.


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

Re: Securing snmpd.conf files

[Craig S. <cs...@dr...>]

On Tue, 14 Jun 2022 at 21:12, Vivek Aditya <viv...@gm...> wrote:

> Is there a way to encrypt passwords in the snmpd.conf file? Currently,
> when we open snmpd.conf file we can look at passwords in plaintext format,
> is there a way to store those passwords in encrypted form. Does net-snmp
> support any encryption/decryption of passwords while reading from
> snmpd.conf?
>
The snmpusm manpage describes a way of making SNMP v3 users.
The passwords are, I believe, stored as MD5 HMAC and not cleartext.

Secondly, if there is no such encryption/decryption mechanism available in
> net-snmp, how can we secure the snmpd.conf file?
>
The user details are stored in a file called snmpd.conf in the snmp the
persistent directory. This file is owned by the user running the snmpd
daemon with permissions 700.

One trick, the daemon doesn't write to the file when you create/update the
user only when it restarts.

 - Craig