Responded in-line below. This will also happen with the following pairings below. Maybe the service probe timeout is on par?
-88/tcp open kerberos-sec Microsoft Windows kerberos-sec +88/tcp open tcpwrapped -464/tcp open kpasswd5 +464/tcp open tcpwrapped -11099/tcp open apc-agent APC PowerChute agent +11099/tcp open unknown -11100/tcp open apc-agent APC PowerChute agent +11100/tcp open unknown -464/tcp open +464/tcp open tcpwrapped On Mon, Jun 6, 2011 at 7:41 AM, Shinnok <[email protected]> wrote: > On Mon, Jun 6, 2011 at 3:27 PM, Shinnok <[email protected]> wrote: > > Hi, > > > > Don't service probes have a certain timeout for the probe response? If > > so then big service latency could cause that exact mismatch also. > > > > Brief grepping revealed the following in service_scan.h: > > #define DEFAULT_SERVICEWAITMS 5000 > > Which should be enough imho, if that's the right timeout value. Does > > that value get dynamically adjusted along the scan? > > > > Another reason could be that some services have resuming state > > capabilities or don't recover that well upon sudden termination of a > > connection, which means that the subsequent timely scans would get > > unexpected results for the service probes. > > > > As you probably noticed, my comment assumes that there is nothing > wrong with the service code, however, given a reproducible case that I > can poke at, I am glad to take a look at the issue. > For eg, for the microsoft-rdp case I would need Windows Version, > Server 2008 R2 Enterprise > Service Pack version, MSRDP client version, RDP Ver 6.1.7600 > Nmap version and on which > subsequent scan does Nmap stop reporting the Service for the port(the > last requirement must be somewhat reproducible). > Nmap 5.5.1 > > Thanks, > > -- > > Shinnok <http://shinnok.com> >
_______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
