Provisiond - simple TCP detector fails to detect services

Debian Linux - 2.6.26-1-amd64 #1 SMP x86_64 GNU/Linux
OpenNMS 1.8.1 from from the ONMS deb repo

Provisiond fails to find open TCP ports defined using the simple TCP detector.

Stock installation, no config changes apart from a provisioning group and a custom foreign source "Printers".

In the foreign source for the provisoining group Printers I have an entry:

        <detector class="org.opennms.netmgt.provision.detector.simple.TcpDetector" name="IPP">
            <parameter value="*" key="banner"/>
            <parameter value="631" key="port"/>
            <parameter value="3000" key="timeout"/>
            <parameter value="2" key="retries"/>
        </detector>

I can then add a simple node definition to the provisioning group:

    <node node-label="print01" foreign-id="1279287949812" building="Printer">
        <interface status="1" snmp-primary="P" ip-addr="1.1.1.1" descr="main">
            <monitored-service service-name="SNMP"/>
            <monitored-service service-name="ICMP"/>
        </interface>
    </node>

Please note that I'm deliberately only defining ICMP and SNMP, so that the rest of the services are detected, not provisioned.

If I then import the provisioning group, it fails to detect the IPP service. In fact any service I define using the Simple TcpDetector seems to fail to be detected, but other such as HTTP are found.


As a sanity check, I nmap the printer from the same host that runs ONMS:


Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2010-07-16 15:26 BST
Interesting ports on print1.mydom.com (1.1.1.1):
Not shown: 1668 closed ports
PORT STATE SERVICE
25/tcp open smtp
80/tcp open http
443/tcp open https
515/tcp open printer
631/tcp open ipp
1521/tcp filtered oracle
1522/tcp filtered rna-lm
1523/tcp filtered cichild-lm
1524/tcp filtered ingreslock
1525/tcp filtered orasrv
8000/tcp open http-alt
9100/tcp open jetdirect

There we see TCP:631 is open, and I can also telnet/nc to it.

If I tcpdump the traffic during the provisioning/detection stage on teh ONMS server, I see nothing unusual. In fact I see some promising interaction, a three way handshake to start a connection on that port, followed by a four way handshake to terminate the connection at both ends. Clearly the detector is running:

14:46:48.195381 IP onms.mydom.com.52636 > print01.mydom.com.ipp: S 4218595545:4218595545(0) win 5840 <mss 1460,sackOK,timestamp 2352565653 0,nop,wscale 7>
14:46:48.196039 IP print01.mydom.com.ipp > onms.mydom.com.52636: S 449433445:449433445(0) ack 4218595546 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 39554513 2352565653>
14:46:48.196089 IP onms.mydom.com.52636 > print01.mydom.com.ipp: . ack 1 win 46 <nop,nop,timestamp 2352565653 39554513>
14:46:49.205409 IP onms.mydom.com.52636 > print01.mydom.com.ipp: F 1:1(0) ack 1 win 46 <nop,nop,timestamp 2352565906 39554513>
14:46:49.206088 IP print01.mydom.com.ipp > onms.mydom.com.52636: . ack 2 win 17376 <nop,nop,timestamp 39554574 2352565906>
14:46:49.206378 IP print01.mydom.com.ipp > onms.mydom.com.52636: F 1:1(0) ack 2 win 17376 <nop,nop,timestamp 39554574 2352565906>
14:46:49.206405 IP onms.mydom.com.52636 > print01.mydom.com.ipp: . ack 2 win 46 <nop,nop,timestamp 2352565906 39554574>


I've gone over the log thoroughly, and can't find much mention of the detection. All I see is:

2010-07-16 15:35:50,112 INFO [Provisiond-TaskScheduler] AsyncDetectorRunner: Attemping to detect service IPP on address 1.1.1.1

~~~ snip ~~~

2010-07-16 15:35:51,123 INFO [NioProcessor-316] IpInterfaceScan$1: Attempted to detect service IPP on address 1.1.1.1: false
2010-07-16 15:35:51,123 INFO [NioProcessor-316] TcpDetector: calling dispose on detector IPP

Where I've "snipped", there is no mention of IPP or port 631 at all, I see no other log entries that are relevant. However, if someone deems it necessary to resolve, I will post the whole thing..
BTW I am logging DEBUG messages for provisiond.


The fact that I've defined the service detector to retry 2 times, and I only see one connection, also makes me think that the detection is successful.

Something is wrong somewhere :)

I posted this on the mailing group, but one one else seemed to be able to help, so I'm raising this as a bug.

Please let me know if you require any further information.



Cheers,
Just