Nmap Development mailing list archives
Re: dev Digest, Vol 136, Issue 51
From: "Mike ." <dmciscobgp () hotmail com>
Date: Thu, 28 Jul 2016 16:42:05 +0000
have you tested any of this on win7? i did EXACTLY what you suggested via the MS loopback adapter install from that
link you gave me. still NO windevice. now you want me to locate a reg key that doesnt exist
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\npcap\LoopbackAdapter
that last part doesnt exist. was i supposed to create it? obviously mymachine does not like npcap for whatever reason
Mike
(the WOW6432) also doesnt exist
________________________________
From: dev <dev-bounces () nmap org> on behalf of dev-request () nmap org <dev-request () nmap org>
Sent: Thursday, July 28, 2016 4:08 PM
To: dev () nmap org
Subject: dev Digest, Vol 136, Issue 51
Send dev mailing list submissions to
dev () nmap org
To subscribe or unsubscribe via the World Wide Web, visit
https://nmap.org/mailman/listinfo/dev
dev Info Page - Nmap<https://nmap.org/mailman/listinfo/dev>
nmap.org
The Nmap dev list is intended to facilitate the development of the free Nmap Security Scanner. It provides an
unmoderated forum for people to contribute ideas, patches,
or, via email, send a message with subject or body 'help' to
dev-request () nmap org
You can reach the person managing the list at
dev-owner () nmap org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dev digest..."
Today's Topics:
1. Bug with nping sequence number (?ric Hoffman)
2. same issues with this npcap (Mike .)
3. Re: same issues with this npcap (?????V5)
----------------------------------------------------------------------
Message: 1
Date: Thu, 28 Jul 2016 00:55:57 -0400
From: ?ric Hoffman <ehoffman () videotron ca>
To: dev () nmap org
Subject: Bug with nping sequence number
Message-ID: <f8fd49f7-b044-3bba-ec9f-8ba9b3b75197 () videotron ca>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello
This have been brought to this mailing list before, by another person,
but no answer was given.
I actually stumbled upon the same issue with nping, that is, the
sequence number is non-linear. Ex:
$ sudo nping --icmp 192.168.200.75 -c 10 --delay 100ms
Starting Nping 0.7.12 ( https://nmap.org/nping ) at 2016-07-27 23:36 EDT
SENT (0.0164s) ICMP [192.168.200.20 > 192.168.200.75 Echo request
(type=8/code=0) id=42883 seq=1] IP [ttl=64 id=28064 iplen=28 ]
RCVD (0.0179s) ICMP [192.168.200.75 > 192.168.200.20 Echo reply
(type=0/code=0) id=42883 seq=1] IP [ttl=64 id=34536 iplen=28 ]
SENT (0.1174s) ICMP [192.168.200.20 > 192.168.200.75 Echo request
(type=8/code=0) id=42883 seq=2] IP [ttl=64 id=28064 iplen=28 ]
RCVD (0.1190s) ICMP [192.168.200.75 > 192.168.200.20 Echo reply
(type=0/code=0) id=42883 seq=2] IP [ttl=64 id=34539 iplen=28 ]
SENT (0.2184s) ICMP [192.168.200.20 > 192.168.200.75 Echo request
(type=8/code=0) id=42883 seq=3] IP [ttl=64 id=28064 iplen=28 ]
RCVD (0.2199s) ICMP [192.168.200.75 > 192.168.200.20 Echo reply
(type=0/code=0) id=42883 seq=3] IP [ttl=64 id=34541 iplen=28 ]
SENT (0.3190s) ICMP [192.168.200.20 > 192.168.200.75 Echo request
(type=8/code=0) id=42883 seq=5] IP [ttl=64 id=28064 iplen=28 ]
RCVD (0.3203s) ICMP [192.168.200.75 > 192.168.200.20 Echo reply
(type=0/code=0) id=42883 seq=5] IP [ttl=64 id=34546 iplen=28 ]
SENT (0.4194s) ICMP [192.168.200.20 > 192.168.200.75 Echo request
(type=8/code=0) id=42883 seq=5] IP [ttl=64 id=28064 iplen=28 ]
RCVD (0.4209s) ICMP [192.168.200.75 > 192.168.200.20 Echo reply
(type=0/code=0) id=42883 seq=5] IP [ttl=64 id=34553 iplen=28 ]
SENT (0.5214s) ICMP [192.168.200.20 > 192.168.200.75 Echo request
(type=8/code=0) id=42883 seq=6] IP [ttl=64 id=28064 iplen=28 ]
RCVD (0.5227s) ICMP [192.168.200.75 > 192.168.200.20 Echo reply
(type=0/code=0) id=42883 seq=6] IP [ttl=64 id=34556 iplen=28 ]
SENT (0.6224s) ICMP [192.168.200.20 > 192.168.200.75 Echo request
(type=8/code=0) id=42883 seq=7] IP [ttl=64 id=28064 iplen=28 ]
RCVD (0.6238s) ICMP [192.168.200.75 > 192.168.200.20 Echo reply
(type=0/code=0) id=42883 seq=7] IP [ttl=64 id=34560 iplen=28 ]
SENT (0.7231s) ICMP [192.168.200.20 > 192.168.200.75 Echo request
(type=8/code=0) id=42883 seq=9] IP [ttl=64 id=28064 iplen=28 ]
RCVD (0.7246s) ICMP [192.168.200.75 > 192.168.200.20 Echo reply
(type=0/code=0) id=42883 seq=9] IP [ttl=64 id=34570 iplen=28 ]
SENT (0.8234s) ICMP [192.168.200.20 > 192.168.200.75 Echo request
(type=8/code=0) id=42883 seq=9] IP [ttl=64 id=28064 iplen=28 ]
RCVD (0.8250s) ICMP [192.168.200.75 > 192.168.200.20 Echo reply
(type=0/code=0) id=42883 seq=9] IP [ttl=64 id=34578 iplen=28 ]
SENT (0.9243s) ICMP [192.168.200.20 > 192.168.200.75 Echo request
(type=8/code=0) id=42883 seq=10] IP [ttl=64 id=28064 iplen=28 ]
RCVD (0.9254s) ICMP [192.168.200.75 > 192.168.200.20 Echo reply
(type=0/code=0) id=42883 seq=10] IP [ttl=64 id=34579 iplen=28 ]
Max rtt: 1.196ms | Min rtt: 0.928ms | Avg rtt: 1.063ms
Raw packets sent: 10 (280B) | Rcvd: 10 (460B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 0.94 seconds
Look at the sequence number, it jumps from 3 to 5, and from 7 to 9, with
the same sequence number repeated twice. I have found out this occur
more likely is you set delay under 100ms, and less likely with 1-second
delay.
I actually looked in the code and found the issue! The way nping work,
in the ProbeMode::start() function (nping/ProbeMode.cc), is that it fill
a packet buffer (with the sequence number), then create a timer (which
call a handler to send the packet at expiration), and call the event
dispatch loop with a timeout 1ms later. So in theory, during a nping
loop, let's suppose the delay is set to 100ms, then the packet is
created and scheduled to be sent 100ms later. Then the event loop is
started with a 101ms timeout (1 ms more than the timer trigger time).
The reasoning behind this is that the timer is bound to always be
triggered before the timeout. However, it is not the case, as explained
bellow.
In the nsock_loop() function (nsock/src/nsock_core.c), used to loop
through events until timeout occurs, the function does basically this:
1 - Check if quit signal is set, and return if so.
2 - Check if there are still pending events, if not, return.
3 - Compute remaining time left before timeout, and if timeout has
occurred, return.
4 - Call the engine loop, which is responsible to dispatch all events
(including our timer), with the remaining time computed at point 3.
5 - Update the current time-of-day, used to compute timeout.
The issue is that there is a race condition. It is well possible that
in one loop, there are still a few milliseconds left for the timer to
trigger. So, at points 3 and 4, nothing happens. And, at point 5, is
it possible that the new time of day put us past the expiration
timeout. If (when) this occurs, the point 3 above compute the new
timeout, and return. Out timer does not get triggered (although it is
still pending in the event pool). This behavior occurs because either
of two reasons. It can be because the system is busy and take more than
1ms to do a loop (which is foreseeable on a serial tty for example,
where just the fact of printing the SEND/RECV packet traces can take a
few ms), or (and this is the most likely culprit) the system time
returned by gettimeofday() is not contiguous. In other word, it does
not increment by 1ms (nor anywhere the precision of the timespec type).
The granularity of the gettimeofday() function is system-dependent, and
depends upon such things as the interrupt rate, if there are high
precision performance counter, etc. Typical values seen can be 10~20ms
steps). All of this to say that when this occurs, the nsock_loop()
function return, and the main ping function generate a new packet, and
setup a new event.
The next time the nsock_loop() function is called, then the last timer
does trigger immediately. Then (possibly before the timeout) the new
timer does trigger too. So, the correct *number* of ICMP packets do get
sent. However, emphasis on the correct *number* of ICMP packets is made
because the ICMP packet content itself is not. In fact, in the
ProbeMode::start() function (nping/ProbeMode.cc), which generate the
actual ICMP packets content, although there are 1024 sendpkt_t entries,
there is actually only one 64KB packet buffer that get assigned and
reused for all packets (u8 pkt[MAX_IP_PACKET_LEN]). And this buffer is
assigned to each output packets. So, when the timeout issue occurs, and
a new packet is generated, the next time nsock_loop() is called, the
last packet (that was support to be sent during the last loop) data has
been overwritten.
So that is the reason why we see duplicate and non-linear sequence number.
To fix this, either we have to fix the ProbeMode::start() function,
taking into account that getting a timeout is a possibility, but this
create the burden of holding more 64KB buffers. Clearly we don't wish
to also have 1024 of those buffers (64MB). Not really embedded-system
friendly. The other way to fix it is to make the nsock_loop() give one
last chance to execute the event loop engine when timeout is detected.
I implemented the second option and it does seem to fix the problem.
--- nmap-master-old/nsock/src/nsock_core.c 2016-07-27
16:35:00.000000000 -0400
+++ nmap-master-new/nsock/src/nsock_core.c 2016-07-28
00:47:52.403081022 -0400
@@ -899,6 +899,7 @@ enum nsock_loopstatus nsock_loop(nsock_p
int msecs_left;
unsigned long loopnum = 0;
enum nsock_loopstatus quitstatus = NSOCK_LOOP_ERROR;
+ int last_try = 0;
gettimeofday(&nsock_tod, NULL);
@@ -934,8 +935,12 @@ enum nsock_loopstatus nsock_loop(nsock_p
if (msec_timeout >= 0) {
msecs_left = MAX(0, TIMEVAL_MSEC_SUBTRACT(loop_timeout, nsock_tod));
if (msecs_left == 0 && loopnum > 0) {
- quitstatus = NSOCK_LOOP_TIMEOUT;
- break;
+ if (!last_try) {
+ last_try = 1;
+ } else {
+ quitstatus = NSOCK_LOOP_TIMEOUT;
+ break;
+ }
}
}
Regards,
Eric
------------------------------
Message: 2
Date: Thu, 28 Jul 2016 15:01:58 +0000
From: "Mike ." <dmciscobgp () hotmail com>
To: nmap-group <dev () nmap org>
Subject: same issues with this npcap
Message-ID:
<BLUPR13MB037208C266C154DAD24CA001C6000 () BLUPR13MB0372 namprd13 prod outlook com>
Content-Type: text/plain; charset="iso-8859-1"
so im giving up on this. i have an interface supposedly up as you can see here :
DEV (SHORT) IP/MASK TYPE UP MTU MAC
eth0 (eth0) 192.168.0.16/24 ethernet up 1500 00:1C:25:74:AB:E1
lo0 (lo0) ::1/128 loopback up -1
lo0 (lo0) 127.0.0.1/8 loopback up -1
and yet again NO recognization as far as a created GUID in nmap or wireshark!
DEV WINDEVICE
eth0 \Device\NPF_{E6793762-9633-432B-B8A6-B4C2F6AA5179}
lo0 <none>
lo0 <none>
<none> \Device\NPF_NdisWanIpv6
<none> \Device\NPF_NdisWanIp
maybe you can have someone else test on win 7 because i am now getting a headache
Mike
(lastly, everytime i go to ENABLE loopback in network connections i get a continuous "identifying..." is that MAC
related or what?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://nmap.org/mailman/private/dev/attachments/20160728/2c12f7b8/attachment.html>
------------------------------
Message: 3
Date: Fri, 29 Jul 2016 00:08:52 +0800
From: ?????V5 <hsluoyz () gmail com>
To: "Mike ." <dmciscobgp () hotmail com>
Cc: nmap-group <dev () nmap org>
Subject: Re: same issues with this npcap
Message-ID:
<CAHGzw11b-PmHn3LV+hsX+R_qyNo5=+k61N3NrzFMvpt0nYc14A () mail gmail com>
Content-Type: text/plain; charset="utf-8"
Hi Mike,
Please do this:
1) Create a Windows loopback adapter based on this:
https://social.technet.microsoft.com/Forums/windows/en-US/259c7ef2-3770-4212-8fca-c58936979851/how-to-install-microsoft-loopback-adapter?forum=w7itpronetworking
Then look at the result of "nmap --iflist", make sure the new loopback
adapter has a "WINDEVICE" value. You can check its IP/MASK for its DEV name.
If even the created Windows loopback adapter doesn't have a "WINDEVICE"
value, you have to use your eth0 as the "Npcap Loopback Adapter". For your
machine, it's:
eth0 \Device\NPF_{E6793762-9633-432B-B8A6-B4C2F6AA5179}
You record the "WINDEVICE" value like the above
"\Device\NPF_{E6793762-9633-432B-B8A6-B4C2F6AA5179}", remove the "NPF_", so
you get "\Device\{E6793762-9633-432B-B8A6-B4C2F6AA5179}"
2) Open the registry, replace the following two registry REG_SZ values with
the above string (no double quote)
1. HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Npcap\LoopbackAdapter
2.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\npcap\LoopbackAdapter
3) Open an Administrator CMD, enter "net stop npcap" and "net start npcap"
to restart the Npcap driver.
4) enter "nmap --iflist" again to look at the result. You should see that
the Npcap Loopback Adapter (lo0) has taken the place of the specified
"WINDEVICE" value.
For the above example, you should see:
lo0 \Device\NPF_{E6793762-9633-432B-B8A6-B4C2F6AA5179}
If you see this, then this hacking method succeeds. You should be able to
normally use commands like "nmap -n -T3 -ttl 64 -d2 -open -Pn -max-retries
1 -F 127.0.0.1" now.
Cheers,
Yang
On Thu, Jul 28, 2016 at 11:01 PM, Mike . <dmciscobgp () hotmail com> wrote:
so im giving up on this. i have an interface supposedly up as you can see
here :
DEV (SHORT) IP/MASK TYPE UP MTU MAC
eth0 (eth0) 192.168.0.16/24 ethernet up 1500 00:1C:25:74:AB:E1
lo0 (lo0) ::1/128 loopback up -1
lo0 (lo0) 127.0.0.1/8 loopback up -1
and yet again NO recognization as far as a created GUID in nmap or
wireshark!
DEV WINDEVICE
eth0 \Device\NPF_{E6793762-9633-432B-B8A6-B4C2F6AA5179}
lo0 <none>
lo0 <none>
<none> \Device\NPF_NdisWanIpv6
<none> \Device\NPF_NdisWanIp
maybe you can have someone else test on win 7 because i am now getting a
headache
Mike
(lastly, everytime i go to ENABLE loopback in network connections i get a
continuous "identifying..." is that MAC related or what?)
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/
-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://nmap.org/mailman/private/dev/attachments/20160729/d67206a2/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ dev mailing list dev () nmap org https://nmap.org/mailman/listinfo/dev ------------------------------ End of dev Digest, Vol 136, Issue 51 ************************************
_______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: dev Digest, Vol 136, Issue 51 Mike . (Jul 28)