Nmap Development mailing list archives
Re: [NSE] ntp-info probing logic?
From: Daniel Miller <bonsaiviking () gmail com>
Date: Wed, 20 Aug 2014 15:26:23 -0500
nnposter, While I'm not necessarily opposed to dropping the success check as you propose, I think there may be a better improvement, too. What results do you get if you apply this patch? diff --git a/scripts/ntp-info.nse b/scripts/ntp-info.nse index 9ca8090..825c811 100644 --- a/scripts/ntp-info.nse +++ b/scripts/ntp-info.nse @@ -75,8 +75,8 @@ action = function(host, port) local buftres, bufrlres local output = stdnse.output_table() - -- This is a ntp v4 mode3 (client) date/time request. - local treq = string.char(0xe3, 0x00, 0x04, 0xfa, 0x00, 0x01, 0x00, 0x00, + -- This is a ntp v2 mode3 (client) date/time request. + local treq = string.char(0xd3, 0x00, 0x04, 0xfa, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, This changes the request from a version 4 to a version 2 packet, which may be more widely supported (version 3 appears to be the consensus, and each version is backwards-compatible with previous ones except for version 1). If this solves your issue, I'd be inclined to just limit the change to this for now. Though your idea does bring to mind the fact that most UDP NSE scripts do not attempt to retransmit packets, which means that network congestion could result in lost results. Dan On Thu, Aug 7, 2014 at 6:12 PM, <nnposter () users sourceforge net> wrote:
Back in March I have proposed a change in how ntp-info behaves to improve its compatibility. http://seclists.org/nmap-dev/2014/q1/341 nnposter wrote:The current version of ntp-info.nse has the following flow: 1. Send NTPv4 request for date/time 2. Exit if it failed 3. Save results 4. Send NTPv2 request for readlist 5. Save results (if any) 6. Return all saved results I am wondering if anybody has any insight into the reason behind the early bailout in step 2. I am seeing systems where the first probe in step 1 fails but the second probe in step 4 does not. In case there is no good reason to keep the current logic then I am proposing the patch below, effectively removing step 2/3.The proposal has not received any feedback so I would like to ask for a reconsideration or some explanation why it would be a bad idea. Cheers, nnposter _______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
_______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: [NSE] ntp-info probing logic? nnposter (Aug 07)
- Re: [NSE] ntp-info probing logic? Daniel Miller (Aug 20)
- Re: [NSE] ntp-info probing logic? nnposter (Aug 22)
- Re: [NSE] ntp-info probing logic? Daniel Miller (Aug 23)
- Re: [NSE] ntp-info probing logic? nnposter (Aug 26)
- Re: [NSE] ntp-info probing logic? nnposter (Aug 22)
- Re: [NSE] ntp-info probing logic? Daniel Miller (Aug 20)