Hello.

Running Observium CE 0.13.10.4586. 

I've run into a strange situation with a single device that I am unable to discover and get added into observium's inventory.  The device is an F5 Load-balancer.  I have 51 other F5's all working beautifully, yet this one seems to be giving me grief for some reason when I try to discover it.

I am able to ping and snmpwalk the device beautifully from the observium server, yet every attempt to run add_device.php returns with the following:
=========
root@observium:~# ./add_device.php lb1-prod-c-qcy examplecommunitystring v2c
Trying v2c community examplecommunitystring ...
No reply on community examplecommunitystring using v2c
Could not reach lb1-prod-c-qcy with given SNMP community using v2c
Trying v2c community examplecommunitystring ...
No reply on community examplecommunitystring using v2c
Could not reach lb1-prod-c-qcy with given SNMP community using v2c
Observium v0.13.10.4586
Add Device

USAGE:
add_device.php <hostname> [community] [v1|v2c] [port] [udp|udp6|tcp|tcp6]
add_device.php <hostname> [any|nanp|anp|ap] [v3] [user] [password] [enckey] [md5|sha] [aes|des] [port] [udp|udp6|tcp|tcp6]

EXAMPLE:
SNMPv1/2c: add_device.php <hostname> [community] [v1|v2c] [port] [udp|udp6|tcp|tcp6]
SNMPv3   :         Defaults : add_device.php <hostname> any v3 [user] [port] [udp|udp6|tcp|tcp6]
           No Auth, No Priv : add_device.php <hostname> nanp v3 [user] [port] [udp|udp6|tcp|tcp6]
              Auth, No Priv : add_device.php <hostname> anp v3 <user> <password> [md5|sha] [port] [udp|udp6|tcp|tcp6]
              Auth,    Priv : add_device.php <hostname> ap v3 <user> <password> <enckey> [md5|sha] [aes|des] [port] [udp|udp6|tcp|tcp6]
=========

yet, as you can see, when I snmpwalk this device, I get responses back just fine.

=========
root@observium:~# snmpwalk -v2c -c examplecommunitystring lb1-prod-c-qcy | head
SNMPv2-MIB::sysDescr.0 = STRING: Linux lb1-prod-c-qcy 2.6.18-164.11.1.el5.1.0.f5app #1 SMP Mon Mar 5 12:40:48 PST 2012 x86_64
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (3523019831) 407 days, 18:09:58.31
SNMPv2-MIB::sysContact.0 = STRING: NOC
SNMPv2-MIB::sysName.0 = STRING: lb1-prod-c-qcy
SNMPv2-MIB::sysLocation.0 = STRING: QDC-C
SNMPv2-MIB::sysServices.0 = INTEGER: 78
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORID.1 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.2 = OID: SNMP-MPD-MIB::snmpMPDCompliance
SNMPv2-MIB::sysORID.3 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
...
=========

I've tried the discovery via v1 as well as v2c, no difference.  Every time I try a walk, I get results back consistently...so it's not like I'm seeing intermittent responses or anything.

I was able to get it to finally discover when I specified the port & transport fields to add_device.php. 

Any thoughts as to what might be failing or not satisfying the add_device.php utility that it would flag this host as not replying?  Why would port/transport being specified make a difference if it's still just standard 161/udp? 

Any hints or suggestions are appreciated.

Cheers,
-Chris