SNMP module should not strip non-standard SNMP port from hostname

Bug #60749 SNMP module should not strip non-standard SNMP port from hostname
Submitted: 2012-01-13 17:39 UTC Modified: 2013-09-11 18:40 UTC
From: lytboris@php.net Assigned: lytboris (profile)
Status: Closed Package: SNMP related
PHP Version: 5.4.0RC5 OS: *
Private report: No CVE-ID: None

 [2012-01-13 17:39 UTC] lytboris@php.net

Description:
------------
From net-snmp/include/net-snmp/types.h, struct snmp_session:
    /** name or address of default peer (may include transport specifier and/or port number) */
    char           *peername;
    /** UDP port number of peer. (NO LONGER USED - USE peername INSTEAD) */
    u_short         remote_port;

php-snmp should place non-standard SNMP port into peername after name resolution.

Test script:
---------------
$session = new SNMP(SNMP::VERSION_1, "$hostname:$port", $community, $timeout, $retries);
$session->get(".1");


Expected result:
----------------
$session->get() will send request to "$hostname:$port"


Actual result:
--------------
$session->get() will send request to "$hostname:161"

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

 [2013-02-08 05:10 UTC] lytboris@php.net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2013-09-11 17:32 UTC] hexetic at gmail dot com

The fix checked-in seems to break passing-in "hostname:port" as $hostname to the snmp functions, e.g.:

<?php
$host = "192.168.0.100:1616";
$rval = snmp2_get ($host, "whatever", "1.3.6.1.4.1.9.9.27");
print $host;
?>

After the call to snmp2_get, $host is "192.168.0.1001616" -- i.e., the colon has been removed. As a result, calling snmp2_get or any of the other functional snmp parameters is likely to fail after the first time.

We are experiencing this with the current version of PHP in Debian Squeeze, i.e.:
$ php --version
PHP 5.4.4-14+deb7u4 (cli) (built: Aug 23 2013 14:37:41) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

The codebase for this version appears to have lytboris@php.net's patch.

 [2013-09-11 18:40 UTC] lytboris@php.net

You need patch from bug report #64124, not this one.

 [2013-09-11 18:41 UTC] hexetic at gmail dot com

In reply to my own comment earlier today, I have checked the "stock" versions of PHP, and I observe that the issue does not seem to exist in a freshly-compiled PHP 5.5.3 or PHP 5.4.19. I will look into possibly reporting this derived issue to Debian instead.