Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

net-snmp 5.3 issues on IRIX 6.5

2 views
Skip to first unread message

Thomas Anders

unread,
Jan 3, 2006, 5:44:30 PM1/3/06
to
The current net-snmp 5.3 release doesn't run too well on IRIX 6.5 and
snmpd fails with a "nlist" error. Unfortunately, none of the Net-SNMP
core developers has access to an IRIX machine to track this down.

We'd highly appreciate if any of you could work with us to fix the
net-snmp issues on IRIX, preferrably by contributing to the
corresponding bug tracker item:

http://sf.net/support/tracker.php?aid=1388562


Cheers,
Thomas

--
Thomas Anders (thomas.anders at blue-cable.de)
for The Net-SNMP Project -- www.net-snmp.org

Herve Boulouis

unread,
Jan 4, 2006, 4:02:48 AM1/4/06
to
On 2006-01-03, Thomas Anders <thomas...@blue-cable.de> wrote:
> The current net-snmp 5.3 release doesn't run too well on IRIX 6.5 and
> snmpd fails with a "nlist" error. Unfortunately, none of the Net-SNMP
> core developers has access to an IRIX machine to track this down.

I recall seeing this bug with net-snmp 5.1 or 5.2 on 64 bits machines
(indigo2, octane, origin and later but not O2) where you have to use
nlist64() and not nlist()

What is your hardware ?

--
Herve Boulouis - Nerim

Thomas Anders

unread,
Jan 4, 2006, 12:50:18 PM1/4/06
to
Herve Boulouis wrote:
> On 2006-01-03, Thomas Anders <thomas...@blue-cable.de> wrote:
>>The current net-snmp 5.3 release doesn't run too well on IRIX 6.5 and
>>snmpd fails with a "nlist" error. Unfortunately, none of the Net-SNMP
>>core developers has access to an IRIX machine to track this down.
>
> I recall seeing this bug with net-snmp 5.1 or 5.2 on 64 bits machines
> (indigo2, octane, origin and later but not O2) where you have to use
> nlist64() and not nlist()

This should be fixed now. We now use nlist64() on IRIX64 systems.

> What is your hardware ?

As I said, *I* don't have any access to an IRIX machine myself and the
reporting IRIX users didn't always specify their hardware.

If you could try out net-snmp 5.3 on IRIX and report back to us, it'd be
much appreciated.


+Thomas

Herve Boulouis

unread,
Jan 5, 2006, 4:58:44 AM1/5/06
to
On 2006-01-04, Thomas Anders <thomas...@blue-cable.de> wrote:
>
>> What is your hardware ?
>
> As I said, *I* don't have any access to an IRIX machine myself and the
> reporting IRIX users didn't always specify their hardware.

Ok, I thought you were the reporting user and not the developper :)

> If you could try out net-snmp 5.3 on IRIX and report back to us, it'd be
> much appreciated.

I'll have a look in the weekend.

Herve Boulouis

unread,
Jan 8, 2006, 6:35:08 AM1/8/06
to
On 2006-01-04, Thomas Anders <thomas...@blue-cable.de> wrote:
>>
>> I recall seeing this bug with net-snmp 5.1 or 5.2 on 64 bits machines
>> (indigo2, octane, origin and later but not O2) where you have to use
>> nlist64() and not nlist()
>
> This should be fixed now. We now use nlist64() on IRIX64 systems.

The 64 bit irix kernel detection code is wrong :

#if defined(irix6) && defined(IRIX64)
#define nlist nlist64
#endif

There is no such IRIX64 symbol defined in the system headers. Just add
-DIRIX64 to CFLAGS when uname == 'IRIX64' to fix the problem.

> If you could try out net-snmp 5.3 on IRIX and report back to us, it'd be
> much appreciated.

Here are the things I had to do to make it work :
(tested on a dual cpu Origin 200 and an octane, both 64 bits machines
running Irix 6.5.26m)

- Use MIPSPro cc (v 7.4.1) in c99 mode (cc -c99). gcc 3.3 gives strange
errors in the kernel headers.

- use the following patch :

diff -urN net-snmp-5.3/agent/mibgroup/mibII/mibII_common.h net-snmp-5.3-irix64/agent/mibgroup/mibII/mibII_common.h
--- net-snmp-5.3/agent/mibgroup/mibII/mibII_common.h 2005-05-01 00:36:16.000000000 +0000
+++ net-snmp-5.3-irix64/agent/mibgroup/mibII/mibII_common.h 2006-01-07 18:34:40.269015200 +0000
@@ -64,7 +64,7 @@
#include <sys/queue.h>
#endif
#if HAVE_SYS_SOCKETVAR_H
-#include <sys/socketvar.h>
+//#include <sys/socketvar.h>
#endif
#if HAVE_NETINET_IP_VAR_H
#include <netinet/ip_var.h>
diff -urN net-snmp-5.3/agent/mibgroup/mibII/tcp.c net-snmp-5.3-irix64/agent/mibgroup/mibII/tcp.c
--- net-snmp-5.3/agent/mibgroup/mibII/tcp.c 2005-11-05 21:40:08.000000000 +0000
+++ net-snmp-5.3-irix64/agent/mibgroup/mibII/tcp.c 2006-01-07 19:01:54.176153600 +0000
@@ -40,7 +40,7 @@
#include <netinet/tcp_timer.h>
#endif
#if HAVE_NETINET_TCP_VAR_H
-#include <netinet/tcp_var.h>
+//#include <netinet/tcp_var.h>
#endif
#if HAVE_NETINET_TCP_FSM_H
#include <netinet/tcp_fsm.h>

The first hunk removes the inclusion of /usr/include/sys/pda.h which contains
#errors when used on an multi cpu machine.

The second hunk resolves a multiple definition problem.

Thomas Anders

unread,
Jan 8, 2006, 2:20:18 PM1/8/06
to
Herve Boulouis wrote:
> The 64 bit irix kernel detection code is wrong :
>
> #if defined(irix6) && defined(IRIX64)
> #define nlist nlist64
> #endif
>
> There is no such IRIX64 symbol defined in the system headers. Just add
> -DIRIX64 to CFLAGS when uname == 'IRIX64' to fix the problem.

Gosh! Thanks for letting us know. Is there any other symbol that is
defined *by default* on 64-bit IRIX machines?


+Thomas

Herve Boulouis

unread,
Jan 8, 2006, 3:57:30 PM1/8/06
to
On 2006-01-08, Thomas Anders <thomas...@blue-cable.de> wrote:
>
> Gosh! Thanks for letting us know. Is there any other symbol that is
> defined *by default* on 64-bit IRIX machines?

I haven't heard of any.

Tony 'Nicoya' Mantler

unread,
Jan 8, 2006, 4:38:30 PM1/8/06
to
In article <dprolj$a18$1...@tapir.blue-cable.net>,
Thomas Anders <thomas...@blue-cable.de> wrote:

Doing this check at compile-time is probably not the right way to do it. A
binary compiled for the N32 ABI can happily run on both IRIX32 and IRIX64
systems, and it is generally recommended to use the N32 ABI for any application
which does not explicitly need 64-bit addressing, even on 64-bit systems.

Ideally the choice between nlist() and nlist64() should be done at runtime
depending on whether you're examining a 32 or 64-bit binary.

You might want to do something like the following when examining the resident
kernel image:

#include <sys/systeminfo.h>
...
char buf[8];
sysinfo(_MIPS_SI_OS_NAME, buf, 7);
if (strcmp("IRIX",buf) == 0) {
nlist(filename, nl);
...
} else if (strcmp("IRIX64",buf) == 0) {
nlist64(filename, nl64);
...
} else { /* panic */ }

It should be noted that nlist() and nlist64() are not drop-in compatible.
nlist() takes an array of "struct nlist" as the second argument, while nlist64()
takes an array of "struct nlist64", where the n_value struct member is widened
to 64 bits.

I don't know what your current code looks like, but it would be advisable to
abstract fetching irix kernel values into a self-contained function rather than
try to substitute different versions of nlist*().


Cheers - Tony 'Nicoya' Mantler :)

--
Tony 'Nicoya' Mantler -- Master of Code-fu -- nic...@ubb.ca
-- http://nicoya.feline.pp.se/ -- http://www.ubb.ca/ --

Thomas Anders

unread,
Jan 9, 2006, 5:46:50 PM1/9/06
to
Tony 'Nicoya' Mantler wrote:
> Ideally the choice between nlist() and nlist64() should be done at runtime
> depending on whether you're examining a 32 or 64-bit binary.

I agree. Can anyone with a *32-bit IRIX* system confirm whether
<nlist.h> has nlist64() on IRIX (so that it compiles at least)?


+Thomas

Walter Roberson

unread,
Jan 9, 2006, 10:42:12 PM1/9/06
to
In article <dpup4r$fah$1...@tapir.blue-cable.net>,

Thomas Anders <thomas...@blue-cable.de> wrote:
>Can anyone with a *32-bit IRIX* system confirm whether
><nlist.h> has nlist64() on IRIX (so that it compiles at least)?

Yes it does -- because the binary which was compiled to run on a 32 bit
system might be asked to examine an arbitrary file that is in ELF64
format. nlist() and nlist64() are not specific to examining the
kernel: they are for examining *files*, and /unix is a file, not
the running kernel.

0 new messages