Problem with Crypto - OpenSSL 1.1.0f - Linux 9.4 (stretch)
I'm trying to build net-snmp-5.7.3 on a raspbery pi running Raspbian 9.4
stretch.
The default packages are OpenSSL 1.1.0f 25 May 2017, libssl-dev
1.1.0f-3+deb9u2.
I configure net-snmp like so,
./configure --with-defaults --with-ldflags=-Bstatic --disable-embedded-perl
--disable-perl-cc-checks --without-perl-modules
And get this config output..
> -
> Net-SNMP configuration summary:
> -
> SNMP Versions Supported:1 2c 3
> Building for: linux
> Net-SNMP Version: 5.7.3
> Network transport support: Callback Unix Alias TCP UDP IPv4Base
> SocketBase TCPBase UDPIPv4Base UDPBase
> SNMPv3 Security Modules: usm
> Agent MIB code:default_modules => snmpv3mibs mibII ucd_snmp
> notification notification-log-mib target agent_mibs agentx disman/event
> disman/schedule utilities host
> MYSQL Trap Logging: unavailable
> Embedded Perl support: disabled
> SNMP Perl modules: disabled
> SNMP Python modules:disabled
> Crypto support from:crypto/ internal ??
> Authentication support: MD5 SHA1
> Encryption support: DES AES
> Local DNSSEC validation:disabled
However make dies at this point.
/bin/bash ../libtool --mode=compile gcc -I../include -I.
> -I../snmplib -fno-strict-aliasing -g -O2 -Ulinux -Dlinux=linux -c -o
> keytools.lo keytools.c
> libtool: compile: gcc -I../include -I. -I../snmplib -fno-strict-aliasing
> -g -O2 -Ulinux -Dlinux=linux -c keytools.c -fPIC -DPIC -o .libs/keytools.o
> keytools.c: In function 'generate_Ku':
> keytools.c:155:25: error: dereferencing pointer to incomplete type
> 'EVP_MD_CTX {aka struct evp_md_ctx_st}'
> ctx = malloc(sizeof(*ctx));
> ^~~~
> keytools.c:265:9: warning: implicit declaration of function
> 'EVP_MD_CTX_cleanup' [-Wimplicit-function-declaration]
> EVP_MD_CTX_cleanup(ctx);
> ^~
> Makefile:98: recipe for target 'keytools.lo' failed
> make[1]: *** [keytools.lo] Error 1
> make[1]: Leaving directory '/root/net-snmp-5.7.3/snmplib'
> Makefile:656: recipe for target 'subdirs' failed
> make: *** [subdirs] Error 1
So the first question is what's wrong with the above ?
I have an Ubuntu box where I build net-snmp fine with crypo, it runs
OpenSSL 1.0.2g so I downgraded the Raspbery PI to 1.0.2o
apt-get remove openssl
> apt-get remove libssl-dev
> cd ~
> wget https://www.openssl.org/source/openssl-1.0.2o.tar.gz
> cd openssl...
> ./config --prefix=/usr/local --openssldir=/usr/local/openssl shared
> make
> make install
> ldconfig
> ldd $(which openssl)
> linux-vdso.so.1 (0x7ee91000)
> /usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f09000)
> libssl.so.1.0.0 => /usr/local/lib/libssl.so.1.0.0 (0x76ea4000)
> libcrypto.so.1.0.0 => /usr/local/lib/libcrypto.so.1.0.0
> (0x76d17000)
> libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76d04000)
> libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76bc5000)
> /lib/ld-linux-armhf.so.3 (0x76f1f000)
>
Everything seems fine but now the configuration summary shows only "Crypto
support from: Internal"
I looked at the configure script to see how it tests for OpenSSL support
and replicated that
#include
> char EVP_md5 ();
> int main(int argc, char *argv[]) {
> return EVP_md5 ();
> ;
> return 0;
> }
When I build that I get the following error showing that the EVP_md5 is
accessible and the crypto library is installed.
# gcc t.c -lcrypto
> t.c:3:6: error: conflicting types for ‘EVP_md5’
> char EVP_md5 ();
> ^~~
> In file included from /usr/local/include/openssl/x509.h:73:0,
> from /usr/local/include/openssl/ssl.h:156,
> from t.c:1:
> /usr/local/include/openssl/evp.h:716:15: note: previous declaration of
> ‘EVP_md5’ was here
> const EVP_MD *EVP_md5(void);
>^~~
I'm not sure if that's the exact test that the configure script is doing
but it's just not detecting
I hacked the configure script to force CRYPTO="crypto" but then compilation
fails elsewhere so I assume I actually have installed OpenSSL incorrectly.
But ether-way I would prefer to fix the first problem above and link
to libssl-dev
1.1.0f
Thanks
--
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
I just filed https://sourceforge.net/p/net-snmp/bugs/2864/ : "clientaddr" doesn't work to set the source address for traps any more. (And given that the code path is the same, I suspect it doesn't work for client requests either). This is a regression against 5.7.3; that code has been restructured so it's not surprising that something has changed. I poked around a little and couldn't find a smoking gun. This is a showstopper for my application: we can't use 5.8 as is with this bug - but that doesn't necessarily mean that the project can't go ahead with the release, there are other needs than mine. Bill -- 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 4/30/18, Venkateswarlu Konamki wrote: > Hi Lee, > > Thanks for the input. I am able to get the correct mac address by using -Ox > in snmpget. I'm glad you've got the problem fixed :) Lee > > Thanks, > > Venkateswarlu.K > > On Sun, Apr 29, 2018 at 9:48 PM, Lee wrote: > >> On 4/28/18, Keith Mendoza wrote: >> > >> > 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. >> >> +1 for loading the MIB. If you had, you'd have probably gotten >> ifPhysAddress OBJECT-TYPE >> SYNTAX PhysAddress >> >> PhysAddress ::= TEXTUAL-CONVENTION >> DISPLAY-HINT "1x:" >> >> and you wouldn't be trying to print the address as a string >> VK> rH"3.6.1.2.1.2.2.1.6.3 = STRING: "$y* >> which looks like it's got a carriage return after the * >> >> Add the -Ox option to display the value as a hex string >> snmpget -v2c -c public -Ox localhost .1.3.6.1.2.1.2.2.1.6.3 >> to see if that is the case. >> >> Regards >> Lee >> >> >> >> 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: DISMAN PING MIB test case question
On Sun, Apr 29, 2018, at 9:20 AM, Bill Fenner wrote: > On Fri, Apr 27, 2018 at 12:15 PM, Keith Mendoza wrote: > > > 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? > > > > T154dismanpingmib_simple runs if the module is compiled in (e.g., > --with-mib-modules=disman/ping), which it isn't by default. After I checked-out the v5.8pre3 tag, and ran autoreconf and configure --enable-blumenthal-aes --with-defaults --with-openssl=; I went ahead and took a closer look at the configuration summary. I spotted the following items in "Agent MIB code": disman/event disman/schedule I'll double-check if these 2 are actually enabling T154dismanpingmib_simple and get back to the group with what I find. > > Bill Now, regarding rerunning autoreconf: When I run this git reports that aclocal.m4 and configure are modified. -- 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: DISMAN PING MIB test case question
On Fri, Apr 27, 2018 at 12:15 PM, Keith Mendoza wrote: > 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? > T154dismanpingmib_simple runs if the module is compiled in (e.g., --with-mib-modules=disman/ping), which it isn't by default. Bill -- 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
RFC: "-@" command line argument to set clientaddr per request/session
I’ve got a local patch that’s been hanging around for a long time to set
session.localaddr from an -@ command line argument. The use case is a bit
esoteric, but has been mentioned a couple of times on the lists: the
existing clientaddr configuration has only one value, so we can’t set
values for IPv4 and IPv6. (And, an even more esoteric case, when you have
trap destinations in different VRFs, you have to be able to set different
source addresses even for the same IP address family.)
It’s paired with a patch that modifies NETSNMP_DS_LIB_CLIENT_ADDR around the
transport = netsnmp_transport_open_client("snmptrap", session.peername);
in the same way that _sess_open() does.
(Yes, source address specification was added to the *sink directives, but
that doesn’t help v3 sessions.)
Is it too late to add this? This occurs to me just because it’s an easier
way to test the transports’ support of clientaddr, by being able to set
clientaddr dynamically via the command line, and I just noticed that this
is broken in 5.8.
Thanks,
Bill
--
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
