Re: Verify AES support when Blumenthal draft is enabled
On Fri, Apr 27, 2018, at 2:40 PM, Robert Story wrote: > On Wed, 25 Apr 2018 10:28:59 -0600 Bart wrote: > BVA> On 04/25/18 10:04, Keith Mendoza wrote: > BVA> > I have submitted a merge request to verify that when the > BVA> > --enable-blumenthal-aes is used in configure that it checks > BVA> > that OpenSSL's aes.h and evp.h are available. Merge request > BVA> > is at > BVA> > https://sourceforge.net/p/net-snmp/code/merge-requests/14/. > BVA> > [...] > BVA> > BVA> Hello Keith, > BVA> > BVA> Are you aware that running something like "brew upgrade > BVA> openssl" brings in a version of openssl on OS/X that is recent > BVA> enough for all Net-SNMP features? > > Regardless, configure should be doing the right thing based on what > is currently installed. > > BVA> Regarding your pull request: > BVA> I'd like to avoid adding AC_CHECK_HEADERS() calls in > BVA> config_project_with_enable because whether or not these > BVA> succeed depend on the compiler flags (-I) and some compiler > BVA> flags are only set at a later phase. > > I agree that header checks inside a feature check is undesirable. > Keith, do you think you could come up with a patch that re-arranges > configure checks that that the desired effect is achieved? Let me give this another go. I think the best solution is when --with-openssl is processed that a variable like "blumenthalcapable" be set based on whether the AES-related functions and headers are available. This will also open it up to other configuration checks that may need the same things. > > Robert -- Thanks, Keith (pantherse) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Summary of meeting between NET-SNMP devs and ICEI
On Fri, Apr 27, 2018, at 7:53 PM, Wes Hardaker wrote: > Robert Story writes: > > |> That discussion is going on over on our admin list. It's not just a > |> few of us running amok. ;-) First, I meant no disrespect when I said "I think it would be best to get full agreement from the team on this." My apologies if my statement came across that way. > > Specifically, there are a bunch of pieces that we're considering > individually. We'll definitely move the repository, we're definitely > going to start sending new issues over there. There is debate about > what to do with the old issues... Many are out of date. Bill Fenner is > looking into converting the wiki pages to markdown. etc... We don't > have an alternative to the SF mailing lists, though hosting them could > be done in an number of places but email lists isn't really the way of > github. For now we'll leave them on sourceforge. But under sourceforge > we can no longer extract all the email addresses to move them, so it'll > require manual process by everyone subscribed if we do move them. We'd > be happy to hear about any other thoughts you have about other > considerations. We are deliberately waiting until after 5.8 gets out > the door to move anything, but our 5.8 announcement will include text > about the upcoming changes. I would very much like to be part of the discussion regarding moving to Github if its amenable to you guys. As for the old issues, Ian and I suggested closing/dropping bugs created before 2012 Nov 8 mainly because of the bug's age and the modify on those seem to be a side effect of possibly some activity from Sourceforge's infrastructure. I'm personally split about what should be done the mailing lists. I find it convenient because it's email that lands in your inbox with your other emails. But, I feel figure out where the conversation has gone so far may require going to the mailing list archive a disadvantage. In my opinion a discussion forum is the best alternative to a mailing list system. Unfortunately, GIthub doesn't have a "discussion forum" system, and users have been begging for it (see https://github.com/dear-github/dear-github/issues/44 but I won't hold my breath on this one). What I would add to the list is having a discussion on the following and target having a process in place before the "grand opening" to Github: * "issues" that would normally go on a "discussion forum" if Github had one. * Whether to stay with the current process of applying changes in the current release branch and master. * How merge requests will be processed. > > -- > Wes Hardaker > Please mail all replies to net-snmp-coders@lists.sourceforge.net -- Thanks, Keith (pantherse) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: ifPhysAddress address is displaying wrong data
On Fri, Apr 27, 2018, at 9:05 PM, Venkateswarlu Konamki wrote: > Hi Robert, > > Iam running snmpd on my ARM embedded device. Since memory is important so i > can't load any extra mibs into it. Any further solition ? You have to load the MIB on the machine where you're running snmpget. Here's the tutorial on how to load a MIB: http://net-snmp.sourceforge.net/wiki/index.php/TUT:Using_and_loading_MIBS > > > > Thanks, > > Venkateswarlu.K > > On Sat, Apr 28, 2018 at 4:02 AM, Robert Story wrote: > > > On Fri, 27 Apr 2018 20:08:19 +0530 Venkateswarlu wrote: > > VK> I am facing one issue with snmp. While fecting the > > VK> ifPhysAddress for my device interfaces, one of the mac address > > VK> is displaying wrong data. > > VK> > > VK> Version : 5.7.3 > > VK> OS: armv7l GNU/Linux > > VK> > > VK> One of my ineterface is having mac address of 24:79:2A:0D:72:48. > > VK> > > VK> While fetching the this MAC address for my interface it is > > VK> giving wrong data. > > VK> > > VK> snmpget -v2c -c public localhost .1.3.6.1.2.1.2.2.1.6.3 > > VK> > > VK> rH"3.6.1.2.1.2.2.1.6.3 = STRING: "$y* > > VK> > > VK> I didn't get any clue so far. Cam someone help ? > > > > Try loading the MIBs, which tell snmpget how to properly display > > the data returned by the agent. > > > > snmpget -m ALL -v2c -c public localhost .1.3.6.1.2.1.2.2.1.6.3 > > > > Robert > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Net-snmp-coders mailing list > Net-snmp-coders@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders -- Thanks, Keith (pantherse) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: ifPhysAddress address is displaying wrong data
Hi Robert, Iam running snmpd on my ARM embedded device. Since memory is important so i can't load any extra mibs into it. Any further solition ? Thanks, Venkateswarlu.K On Sat, Apr 28, 2018 at 4:02 AM, Robert Story wrote: > On Fri, 27 Apr 2018 20:08:19 +0530 Venkateswarlu wrote: > VK> I am facing one issue with snmp. While fecting the > VK> ifPhysAddress for my device interfaces, one of the mac address > VK> is displaying wrong data. > VK> > VK> Version : 5.7.3 > VK> OS: armv7l GNU/Linux > VK> > VK> One of my ineterface is having mac address of 24:79:2A:0D:72:48. > VK> > VK> While fetching the this MAC address for my interface it is > VK> giving wrong data. > VK> > VK> snmpget -v2c -c public localhost .1.3.6.1.2.1.2.2.1.6.3 > VK> > VK> rH"3.6.1.2.1.2.2.1.6.3 = STRING: "$y* > VK> > VK> I didn't get any clue so far. Cam someone help ? > > Try loading the MIBs, which tell snmpget how to properly display > the data returned by the agent. > > snmpget -m ALL -v2c -c public localhost .1.3.6.1.2.1.2.2.1.6.3 > > Robert > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Summary of meeting between NET-SNMP devs and ICEI
Robert Story writes: |> That discussion is going on over on our admin list. It's not just a |> few of us running amok. ;-) Specifically, there are a bunch of pieces that we're considering individually. We'll definitely move the repository, we're definitely going to start sending new issues over there. There is debate about what to do with the old issues... Many are out of date. Bill Fenner is looking into converting the wiki pages to markdown. etc... We don't have an alternative to the SF mailing lists, though hosting them could be done in an number of places but email lists isn't really the way of github. For now we'll leave them on sourceforge. But under sourceforge we can no longer extract all the email addresses to move them, so it'll require manual process by everyone subscribed if we do move them. We'd be happy to hear about any other thoughts you have about other considerations. We are deliberately waiting until after 5.8 gets out the door to move anything, but our 5.8 announcement will include text about the upcoming changes. -- Wes Hardaker Please mail all replies to net-snmp-coders@lists.sourceforge.net -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Net-SNMP 5.8.pre3 available
A pre-release version of the next major Net-SNMP release is now available for testing. Net-SNMP 5.8.pre3 can be downloaded from: https://sourceforge.net/projects/net-snmp/files/net-snmp/5.8-pre-releases/ Partial summary of changes since since 5.8.pre2: *5.8.pre3* snmplib: - Asn1: BUG: 2828: from "Google Autofuzz project": fix off-by-one heap access for opaque types (and an adjacent bug that was not in 5.4, noticed by code inspection) - Asn1: from "Google Autofuzz project": propagate error from asn_parse_length snmpd: - BUG: 2810: from "Minzhuan Gong": fix compile with --enable-read-only - BUG: 2845: fix compilation error with NETSNMP_NO_WRITE_SUPPORT - BUG: 2846: fix agent compile when both --enable-read-only and --disable-set-support are given. - Com2sec and com2sec6 SOURCE values may deny sources as well as permit. - TLSTM MIB: Fix support for sha256, 384 and 512 fingerprints - BUG: 2830: Make the agentxperms keyword work again agentx: - From "Google AutoFuzz project": account for the nul character we will add to the string. - From "Google Autofuzz project": additional agentx protocol parser bounds checking Win32: - Add support for the DTLS-UDP and TLS-TCP transports - Win32/MSVC general cleanup unspecified: - Fix bug #2832 for building new checkbandwidth script - Many fixes found by Coverity scans We're closing in on a final release. The current plan is to have release candidate 1 next week. Robert -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Summary of meeting between NET-SNMP devs and ICEI
On Wed, 25 Apr 2018 13:24:12 -0700 Keith wrote: KM> On Wed, Apr 25, 2018, at 12:08 PM, Robert Story wrote: KM> > We've had recent discussions on this, and I think we'll be KM> > moving the source to github in the near future. KM> KM> I think it would be best to get full agreement from the team on KM> this. I hear bits-and-pieces that there have been some move in KM> that direction. However, I think there should be a separate KM> discussion just on that topic and what it would entail to KM> officially move the Net-SNMP project over. That discussion is going on over on our admin list. It's not just a few of us running amok. ;-) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Verify AES support when Blumenthal draft is enabled
On Wed, 25 Apr 2018 10:53:35 -0700 Keith wrote: KM> I feel the best solution would be to remove the typecasts going KM> on inside sc_get_openssl_hashfn(). It seems to me that having KM> these typecasts there is triggering the implicit declaration of KM> EVP_sha512() that lead to the crash we both encountered. KM> However, I don't want testing the "best" solution to block 5.8 KM> release. The crash was caused by the darwin header defining things it shouldn't have. The configure fix is the way to go.. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: 5.8 testing status
On Thu, 26 Apr 2018 22:07:27 -0400 Bill wrote:
BF> >>> (The context is that the library now tries to suppress
BF> >>> converting traps from v1 to v2 or vice versa if there is no
BF> >>> trap sink of the right type, but, it does not know how to
BF> >>> treat agentx sessions so doesn't count them - so if there's
BF> >>> only an agentx session open it may not send *any* traps
BF> >>> since it "knows" there are no v1 or v2 trap sessions open)
Drat. I should have added a log message when neither matched.
BF> It's plausible that a workaround as simple as
BF>
BF> +/*
BF> + * We lie about being SNMPv3, because ...
BF> + */
BF> if (add_trap_session(main_session, AGENTX_MSG_NOTIFY, 1,
BF> - AGENTX_VERSION_1)) {
BF> + SNMP_VERSION_3)) {
BF>
BF> would work. (I picked V3 because you can't disable it, unlike
BF> v2c.) I also didn't feel like writing the rest of the
BF> comment :-)
Hmm.. I'm not a fan of lying if it's avoidable... The fix should be
to recognize the agentx sessions properly...
Robert
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: ifPhysAddress address is displaying wrong data
On Fri, 27 Apr 2018 20:08:19 +0530 Venkateswarlu wrote: VK> I am facing one issue with snmp. While fecting the VK> ifPhysAddress for my device interfaces, one of the mac address VK> is displaying wrong data. VK> VK> Version : 5.7.3 VK> OS: armv7l GNU/Linux VK> VK> One of my ineterface is having mac address of 24:79:2A:0D:72:48. VK> VK> While fetching the this MAC address for my interface it is VK> giving wrong data. VK> VK> snmpget -v2c -c public localhost .1.3.6.1.2.1.2.2.1.6.3 VK> VK> rH"3.6.1.2.1.2.2.1.6.3 = STRING: "$y* VK> VK> I didn't get any clue so far. Cam someone help ? Try loading the MIBs, which tell snmpget how to properly display the data returned by the agent. snmpget -m ALL -v2c -c public localhost .1.3.6.1.2.1.2.2.1.6.3 Robert -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: [PATCH RFC] Add Travis and Appveyor CI support
On Wed, 25 Apr 2018 12:05:06 -0600 Bart wrote: BVA> On 04/25/18 11:54, Keith Mendoza wrote: BVA> > Out of curiosity, do you have a "fork" of Net-SNMP on github BVA> > to connect it to Travis and Appveyor? BVA> BVA> If you are looking for a Net-SNMP repository on github, please BVA> use https://github.com/net-snmp/net-snmp. I hope Wes will BVA> connect that repository to Travis and Appveyor. Note that there isn't any automatic synchronization between SF and github yet, and SF is still considered the master. Robert -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Verify AES support when Blumenthal draft is enabled
On Wed, 25 Apr 2018 10:28:59 -0600 Bart wrote: BVA> On 04/25/18 10:04, Keith Mendoza wrote: BVA> > I have submitted a merge request to verify that when the BVA> > --enable-blumenthal-aes is used in configure that it checks BVA> > that OpenSSL's aes.h and evp.h are available. Merge request BVA> > is at BVA> > https://sourceforge.net/p/net-snmp/code/merge-requests/14/. BVA> > [...] BVA> BVA> Hello Keith, BVA> BVA> Are you aware that running something like "brew upgrade BVA> openssl" brings in a version of openssl on OS/X that is recent BVA> enough for all Net-SNMP features? Regardless, configure should be doing the right thing based on what is currently installed. BVA> Regarding your pull request: BVA> I'd like to avoid adding AC_CHECK_HEADERS() calls in BVA> config_project_with_enable because whether or not these BVA> succeed depend on the compiler flags (-I) and some compiler BVA> flags are only set at a later phase. I agree that header checks inside a feature check is undesirable. Keith, do you think you could come up with a patch that re-arranges configure checks that that the desired effect is achieved? Robert -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: DISMAN PING MIB test case question
Bill, On Thu, Apr 26, 2018, at 6:54 PM, Bill Fenner wrote: > I do not think the DISMAN PING module builds anywhere but Linux. I am not > a fan of the existing implementation since it is synchronous. Would it be worth it to update RUNFULLTEST or T154dismanpingmib_simple to only run on Linux? > > (I have a from-scratch asynchronous rewrite sitting around languishing that > I haven't tested anywhere but Linux; raw sockets are pretty notoriously > incompatible across OSes. It needs a bit of cleanup and support for > sending/receiving IPv6 packets...) Maybe we can revisit this code after 5.8 is released? > > Bill > > > On Thu, Apr 26, 2018 at 2:01 PM, Keith Mendoza wrote: > > > I have a question about what permissions DISMAN PING MIB test case > > expects. I'm running on a macOS 12.3.4 with --enable-blumenthal-aes > > --with-openssl= --with-defaults. When I > > run make test as my normal user I get "skipped: Not permitted to create raw > > sockets". However, when I run make test using "sudo make test" I instead > > get "skipped: USING_DISMAN_PING_MIB_MODULE is not defined". Should I be > > running "make test" as root? > > > > -- > > Thanks, > > Keith (pantherse) > > > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > Net-snmp-coders mailing list > > Net-snmp-coders@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders > > -- Thanks, Keith (pantherse) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: ifPhysAddress address is displaying wrong data
On Fri, Apr 27, 2018, at 7:38 AM, Venkateswarlu Konamki wrote: > HI, > > I am facing one issue with snmp. While fecting the ifPhysAddress for my > device interfaces, one of the mac address is displaying wrong data. > > Version : 5.7.3 > OS: armv7l GNU/Linux Can you please provide more information on the Linux distro you're running. > > One of my ineterface is having mac address of 24:79:2A:0D:72:48. > > While fetching the this MAC address for my interface it is giving wrong > data. > > snmpget -v2c -c public localhost .1.3.6.1.2.1.2.2.1.6.3 > > rH"3.6.1.2.1.2.2.1.6.3 = STRING: "$y* Can you provide the full output from snmpget, and please provide the version of Net-SNMP that you are running. > > > I didn't get any clue so far. Cam someone help ? > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Net-snmp-coders mailing list > Net-snmp-coders@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders -- Thanks, Keith (pantherse) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
ifPhysAddress address is displaying wrong data
HI, I am facing one issue with snmp. While fecting the ifPhysAddress for my device interfaces, one of the mac address is displaying wrong data. Version : 5.7.3 OS: armv7l GNU/Linux One of my ineterface is having mac address of 24:79:2A:0D:72:48. While fetching the this MAC address for my interface it is giving wrong data. snmpget -v2c -c public localhost .1.3.6.1.2.1.2.2.1.6.3 rH"3.6.1.2.1.2.2.1.6.3 = STRING: "$y* I didn't get any clue so far. Cam someone help ? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
