php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23051 snmpwalkoid doesnt work on alphas
Submitted: 2003-04-04 07:31 UTC Modified: 2004-02-20 00:13 UTC
From: csmall at enc dot com dot au Assigned: harrie (profile)
Status: Closed Package: SNMP related
PHP Version: 4CVS-2003-04-04 (stable) OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: csmall at enc dot com dot au
New email:
PHP Version: OS:

 

 [2003-04-04 07:31 UTC] csmall at enc dot com dot au
This problem has been around at least since 4.3.2, you might also want to look at http://bugs.debian.org/185534

snmprealwalk and snmpwalkoid fail to work properly on my alpha.  snmpwalk used to not work but now does.  Version is
php4-STABLE-200304041230

./configure line was
'--enable-debug' \
'--with-bz2' \
'--with-snmp' \
'--with-openssl' \

This is the test code:
<?
$host='myhostname';
$community='mysecret';

$ifDescr = snmpwalkoid("$host","$community","interfaces.ifTable.ifEntry.ifDescr");
var_dump($ifDescr);

?>

Output is:
---------
array(1) {
  ["interfaces.ifTable.ifEntry.ifDescr.1"]=>
  string(42) "interfaces.ifTable.ifEntry.ifDescr.6 = br0"
}
--------
This is broken, as this is the result of the last (6th) interface in the place of the first, notice the key says ifDesc.1 and the result says ifDescr.6

This is what a i386 running Debian 4.2.3-13 on the exact same script does:
---------
array(6) {
  ["interfaces.ifTable.ifEntry.ifDescr.1"]=>
  string(41) "interfaces.ifTable.ifEntry.ifDescr.1 = lo"
  ["interfaces.ifTable.ifEntry.ifDescr.2"]=>
  string(43) "interfaces.ifTable.ifEntry.ifDescr.2 = eth0"
  ["interfaces.ifTable.ifEntry.ifDescr.3"]=>
  string(43) "interfaces.ifTable.ifEntry.ifDescr.3 = eth1"
  ["interfaces.ifTable.ifEntry.ifDescr.4"]=>
  string(43) "interfaces.ifTable.ifEntry.ifDescr.4 = gre0"
  ["interfaces.ifTable.ifEntry.ifDescr.5"]=>
  string(43) "interfaces.ifTable.ifEntry.ifDescr.5 = sit0"
  ["interfaces.ifTable.ifEntry.ifDescr.6"]=>
  string(42) "interfaces.ifTable.ifEntry.ifDescr.6 = br0"
}
------

I ran some tests on the 4.2.3 code and it was definitely returning the right and multiple values.  I basically enabled the Debug() line in snmp.c and saw the return string come back the way I expected.


So it looks like some pointer or array is getting overwritten.  I tried linking in electric fence but libsnmp is too buggy and it died within the library loading up the mibs.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-04-04 10:55 UTC] sniper@php.net
But does 4.2.3 work on that alpha?
Or is it common for any platform??

 [2003-04-04 19:07 UTC] csmall at enc dot com dot au
After more testing, there are two bugs in this module
 1) Something breaks in the OID resolver, you get the entire MIB tree.  This occured on alpha and i386 and seems to be fixed in Debian 4.2.3-13  It does suggest you have a problem with the net-snmp library as -9 and -13 are linked to ucd-snmp 4.2 while -12 is net-snmp 5.
 2) Something is seriously wrong with the array handling and you get part of the table or just junk text.  This happens on the alpha at least but not the i386.

Here are my results, see key below to work out what I did:

Arch  Ver      N/SW N/SWO N/SRW C/SW C/SWO C/SRW
i386  4.2.3-9  OK   OK    OK    OK   OK    OK
i386  4.2.3-12 OK   OK    OK    WT   WT    WT
i386  4.2.3-13 OK   OK    OK    OK   OK    OK
alpha 4.2.3-9  OK   ST    ST    OK   ST    ST
alpha 4.2.3-12 WT   WT    WT    WT   WT    WT
alpha 4.2.3-13 OK   BA    BA    OK   BA    BA
alpha STABLE   OK   BA    BA    OK   BA    BA

The Arch should be obvious
Ver is version the 4.2.3-X is a Debian version, STABLE means the one I downloaded php4-STABLE-200304041230
Then the various functions
  N/SW  Numeric OID, snmpwalk()
  N/SWO Numeric OID, snmpwalkoid()
  N/SRW Numeric OID, snmprealwalk()
  C/SW  Character OID, snmpwalk()
  C/SWO Character OID, snmpwalkoid()
  C/SRW Character OID, snmprealwalk()
Numeric OID is ".1.3.6.1.2.1.2.2.1.2"
Character OID is "interfaces.ifTable.ifEntry.ifDescr"
The results
OK - obviously it worked fine!
WT - Whole tree. Get error message of "Invalid object identifier" then it scans the entire MIB tree of remote object.
BA - Broken Array, Result shown in previous message, but you get only one item of the array. The key is the first item, the value is the last.
ST - Strange text, check THIS out (its always the same text):
array(1) {
  ["        occur between two tag values.  A tag value may not
         have a zero length.  These constraints imply certain
         restrictions on the contents of this object:

             - There cannot be a leadingH?/"]=>
  string(42) "interfaces.ifTable.ifEntry.ifDescr.6 = br0"
}
As i said, strange text....
 [2003-04-23 04:16 UTC] sniper@php.net
Assigning to Harrie who is the maintainer of ext/snmp.
 [2003-07-16 01:05 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
Make sure the snapshot is build later than Jul 16, 2003 05:30!!


 [2003-07-21 01:28 UTC] sniper@php.net
No feedback, assumed fixed.

 [2004-02-19 19:23 UTC] csmall at enc dot com dot au
This bug is still open, i will try the snapshot
 [2004-02-19 20:27 UTC] csmall at enc dot com dot au
That snapshot version worked, but i got this message too. any idea what this means?

/home/csmall/Projects/php4/php4-STABLE-200402192230/ext/snmp/snmp.c(239) :  Freeing 0x1207B69A0 (55 bytes), script=poller.php
Last leak repeated 7 times
/home/csmall/Projects/php4/php4-STABLE-200402192230/ext/snmp/snmp.c(423) :  Freeing 0x1207B4EA0 (24 bytes), script=poller.php
Last leak repeated 7 times
 [2004-02-20 00:13 UTC] sniper@php.net
This bug is fixed in CVS, so please leave _THIS_ report closed. Open a new report about the leaks. 

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 00:01:33 2024 UTC