OS X 10.6 Problems with privileged scans

[Tom Sellers]

I saw this while going through the TODO file:

o Potential OS X 10.6 problems.  There are two issues reported by the
   same user which may be related:
   http://seclists.org/nmap-dev/2009/q3/0936.html,
   http://seclists.org/nmap-dev/2009/q3/0996.html.  One is that Nmap
   hangs doing nothing and needs to be killed with Ctrl-C, and the
   other is that it dies after printing "Initiating UDP Scan".  Another
   reported the same problem at
   http://seclists.org/nmap-dev/2009/q3/0990.html, where it dies after
   the first ARP request is sent.  But Brandon has run Nmap on 10.6
   without problems.  It is a bit of a mystery. [David]


I have this problem on my Snow Leopard system.  Normal users can run
certain scans, but root cannot.  Even simple scans are affected..

sudo nmap -sP -d9 scanme.nmap.org   chokes here until I kill it:

**********************************************************************
Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-10-15 19:04 CDT
The max # of sockets we are using is: 0
--------------- Timing report ---------------
   hostgroups: min 1, max 100000
   rtt-timeouts: init 1000, min 100, max 10000
   max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
   parallelism: min 0, max 0
   max-retries: 10, host-timeout: 0
   min-rate: 0, max-rate: 0
---------------------------------------------
Initiating Ping Scan at 19:04
Scanning 64.13.134.52 [4 ports]
Pcap filter: dst host 192.168.200.77 and (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52)))
Packet capture filter (device en1): dst host 192.168.200.77 and (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52)))
SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 echo request (type=8/code=0) ttl=51 id=6159 iplen=28
SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:443 S ttl=50 id=14485 iplen=44  seq=1618135438 win=3072 <mss 1460>
SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:80 A ttl=53 id=3056 iplen=40  seq=1618135438 win=2048 ack=3449250024
SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 Timestamp request (type=13/code=0) ttl=39 id=29241 iplen=40
**TIMING STATS** (0.0040s): IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay, timeout/srtt/rttvar/
    Groupstats (1/1 incomplete): 4/*/*/*/*/* 10.00/75/* 1000000/-1/-1
    64.13.134.52: 4/0/0/4/0/0 10.00/75/0 1000000/-1/-1
Current sending rates: 3988.04 packets / s, 151545.36 bytes / s.
Overall sending rates: 3988.04 packets / s, 151545.36 bytes / s.


**********************************************************************


This appears to be a change in behavior (BUG) introduced in Snow Leopard
and other projects are running into it as well.

Wireshark has a pretty informative open item:
        https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3980

Basically it looks like the bpf interfaces are goofed and the only traffic
you cannot see is that which YOUR machine sent.  In my case, it is over a
wireless adapter which worked fine pre-upgrade as well as under Windows 7.

I will try digging into this some more, but I wanted to go ahead and throw
this data out there.

Tom




_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[David Fifield]

On Thu, Oct 15, 2009 at 07:10:49PM -0500, Tom Sellers wrote:

> I saw this while going through the TODO file:
>
> o Potential OS X 10.6 problems.  There are two issues reported by the
>   same user which may be related:
>   http://seclists.org/nmap-dev/2009/q3/0936.html,
>   http://seclists.org/nmap-dev/2009/q3/0996.html.  One is that Nmap
>   hangs doing nothing and needs to be killed with Ctrl-C, and the
>   other is that it dies after printing "Initiating UDP Scan".  Another
>   reported the same problem at
>   http://seclists.org/nmap-dev/2009/q3/0990.html, where it dies after
>   the first ARP request is sent.  But Brandon has run Nmap on 10.6
>   without problems.  It is a bit of a mystery. [David]
>
>
> I have this problem on my Snow Leopard system.  Normal users can run
> certain scans, but root cannot.  Even simple scans are affected..
>
> sudo nmap -sP -d9 scanme.nmap.org   chokes here until I kill it:
>
> **********************************************************************
> Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-10-15 19:04 CDT
> The max # of sockets we are using is: 0
> --------------- Timing report ---------------
>   hostgroups: min 1, max 100000
>   rtt-timeouts: init 1000, min 100, max 10000
>   max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
>   parallelism: min 0, max 0
>   max-retries: 10, host-timeout: 0
>   min-rate: 0, max-rate: 0
> ---------------------------------------------
> Initiating Ping Scan at 19:04
> Scanning 64.13.134.52 [4 ports]
> Pcap filter: dst host 192.168.200.77 and (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52)))
> Packet capture filter (device en1): dst host 192.168.200.77 and (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52)))
> SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 echo request (type=8/code=0) ttl=51 id=6159 iplen=28
> SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:443 S ttl=50 id=14485 iplen=44  seq=1618135438 win=3072 <mss 1460>
> SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:80 A ttl=53 id=3056 iplen=40  seq=1618135438 win=2048 ack=3449250024
> SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 Timestamp request (type=13/code=0) ttl=39 id=29241 iplen=40
> **TIMING STATS** (0.0040s): IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay, timeout/srtt/rttvar/
>    Groupstats (1/1 incomplete): 4/*/*/*/*/* 10.00/75/* 1000000/-1/-1
>    64.13.134.52: 4/0/0/4/0/0 10.00/75/0 1000000/-1/-1
> Current sending rates: 3988.04 packets / s, 151545.36 bytes / s.
> Overall sending rates: 3988.04 packets / s, 151545.36 bytes / s.
>
> **********************************************************************
>
>
> This appears to be a change in behavior (BUG) introduced in Snow Leopard
> and other projects are running into it as well.
>
> Wireshark has a pretty informative open item:
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3980
>
> Basically it looks like the bpf interfaces are goofed and the only traffic
> you cannot see is that which YOUR machine sent.  In my case, it is over a
> wireless adapter which worked fine pre-upgrade as well as under Windows 7.

Tom, you're awesome. I didn't have a clue about this. I think the most
pressing is to figure out what's causing the hang/crash. Try building
with "make debug", then run the scan using the debug nmap:

cd nmap
sudo ./nmap -sP -d9 scanme.nmap.org

Find out the PID of the nmap process, then run

sudo gdb ./nmap $pid

Type "backtrace" to see where in the code it's hanging.

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[Tom Sellers]

David Fifield wrote:

> cd nmap
> sudo ./nmap -sP -d9 scanme.nmap.org
>
> Find out the PID of the nmap process, then run
>
> sudo gdb ./nmap $pid
>
> Type "backtrace" to see where in the code it's hanging.
>
> David Fifield
>

Ok, here we go...


Reading symbols for shared libraries .+++++.. done
0x00007fff813e0364 in read ()
(gdb) backtrace
#0  0x00007fff813e0364 in read ()
#1  0x00000001003465fc in pcap_read_bpf ()
#2  0x000000010034824b in pcap_next ()
#3  0x00000001000321ac in readip_pcap (pd=0x100401c40, len=0x7fff5fbfad84, to_usec=999054, rcvdtime=0x7fff5fbface0, linknfo=0x7fff5fbfad90, validate=true) at tcpip.cc:2330
#4  0x0000000100087166 in get_ping_pcap_result (USI=0x100401710, stime=0x7fff5fbfae10) at scan_engine.cc:4413
#5  0x000000010008c3e7 in waitForResponses (USI=0x100401710) at scan_engine.cc:4990
#6  0x00000001000913cb in ultra_scan (Targets=@0x7fff5fbfaf80, ports=0x7fff5fbfc6e0, scantype=PING_SCAN, to=0x1001e8964) at scan_engine.cc:5279
#7  0x0000000100020152 in massping (hostbatch=0x100820200, num_hosts=1, ports=0x7fff5fbfc6e0) at targets.cc:424
#8  0x0000000100022e0c in nexthost (hs=0x10081fc00, exclude_group=0x0, ports=0x7fff5fbfc6e0, pingtype=122) at targets.cc:578
#9  0x000000010001ab9e in nmap_main (argc=4, argv=0x7fff5fbffc30) at nmap.cc:1716
#10 0x000000010000b5c5 in main (argc=4, argv=0x7fff5fbffc30) at main.cc:205
(gdb)


Based on my reading of this the code has hung trying to read from the interface.
Is that correct?  I am surprised that the code would block and not time out.

Should I do anything to increase the visibility into libpcap?

Tom



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[walts]

I've been dealing with this from version 5.05 BETA1, and I have the  
same symptoms as Tom.

I have no problem with nmap version 5.0

I have  no problem with Wireshark version 1.2.0 under OS X 10.6.1 once  
I applied the recommended patch, sudo chmod g+w /dev/bpf*

Here is the backtrace from my nmap5.05BETA1:

Reading symbols for shared libraries .++++++.. done
0x00007fff8653b364 in read ()
(gdb) backtrace
#0  0x00007fff8653b364 in read ()
#1  0x00000001001635fc in pcap_read_bpf ()
#2  0x000000010016524b in pcap_next ()
#3  0x0000000100012e6f in readip_pcap (pd=0x100201900,  
len=0x7fff5fbfaccc, to_usec=999756, rcvdtime=0x7fff5fbfaca0,  
linknfo=0x7fff5fbfacd0, validate=true) at tcpip.cc:2330
#4  0x0000000100036fd7 in waitForResponses (USI=0x100201410) at  
scan_engine.cc:4414
#5  0x000000010003a8ff in ultra_scan (Targets=@0x7fff5fbfaf00,  
ports=0x100201480, scantype=STYPE_UNKNOWN, to=0x1000c97a4) at  
scan_engine.cc:5280
#6  0x000000010000cd24 in ~vector [inlined] () at targets.cc:429
#7  0x000000010000cd24 in ~vector [inlined] () at /usr/include/c++/
4.2.1/bits/stl_vector.h:271
#8  0x000000010000cd24 in massping (hostbatch=0x1, num_hosts=1,  
ports=0x7fff5fbfc740) at targets.cc:429
#9  0x000000010000d3a2 in nexthost (hs=0x10081fc00, exclude_group=0x0,  
ports=0x7fff5fbfc740, pingtype=122) at targets.cc:583
#10 0x0000000100008613 in nmap_main (argc=4, argv=0x7fff5fbffb78) at  
nmap.cc:1722
#11 0x0000000100003bdb in main (argc=4, argv=0x7fff5fbffb78) at  
main.cc:205
(gdb)

It is different from Tom's, but I have no idea what I'm looking at :-)

Walt

On Oct 15, 2009, at 9:03 PM, Tom Sellers wrote:

> David Fifield wrote:
>> cd nmap
>> sudo ./nmap -sP -d9 scanme.nmap.org
>> Find out the PID of the nmap process, then run
>> sudo gdb ./nmap $pid
>> Type "backtrace" to see where in the code it's hanging.
>> David Fifield
>
> Ok, here we go...
>
>
> Reading symbols for shared libraries .+++++.. done
> 0x00007fff813e0364 in read ()
> (gdb) backtrace
> #0  0x00007fff813e0364 in read ()
> #1  0x00000001003465fc in pcap_read_bpf ()
> #2  0x000000010034824b in pcap_next ()
> #3  0x00000001000321ac in readip_pcap (pd=0x100401c40,  
> len=0x7fff5fbfad84, to_usec=999054, rcvdtime=0x7fff5fbface0,  
> linknfo=0x7fff5fbfad90, validate=true) at tcpip.cc:2330
> #4  0x0000000100087166 in get_ping_pcap_result (USI=0x100401710,  
> stime=0x7fff5fbfae10) at scan_engine.cc:4413
> #5  0x000000010008c3e7 in waitForResponses (USI=0x100401710) at  
> scan_engine.cc:4990
> #6  0x00000001000913cb in ultra_scan (Targets=@0x7fff5fbfaf80,  
> ports=0x7fff5fbfc6e0, scantype=PING_SCAN, to=0x1001e8964) at  
> scan_engine.cc:5279
> #7  0x0000000100020152 in massping (hostbatch=0x100820200,  
> num_hosts=1, ports=0x7fff5fbfc6e0) at targets.cc:424
> #8  0x0000000100022e0c in nexthost (hs=0x10081fc00,  
> exclude_group=0x0, ports=0x7fff5fbfc6e0, pingtype=122) at targets.cc:
> 578
> #9  0x000000010001ab9e in nmap_main (argc=4, argv=0x7fff5fbffc30) at  
> nmap.cc:1716
> #10 0x000000010000b5c5 in main (argc=4, argv=0x7fff5fbffc30) at  
> main.cc:205
> (gdb)
>
>
> Based on my reading of this the code has hung trying to read from  
> the interface.
> Is that correct?  I am surprised that the code would block and not  
> time out.
>
> Should I do anything to increase the visibility into libpcap?
>
> Tom
>
>
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://SecLists.Org

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[David Fifield]

On Thu, Oct 15, 2009 at 09:49:20PM -0400, SCRIVENS WALTER wrote:
> I've been dealing with this from version 5.05 BETA1, and I have the same
> symptoms as Tom.
>
> I have no problem with nmap version 5.0

Tom, does version 5.00 work for you too?

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[Tom Sellers]

David Fifield wrote:
> On Thu, Oct 15, 2009 at 09:49:20PM -0400, SCRIVENS WALTER wrote:
>> I've been dealing with this from version 5.05 BETA1, and I have the same
>> symptoms as Tom.
>>
>> I have no problem with nmap version 5.0
>
> Tom, does version 5.00 work for you too?
>
> David Fifield

No, it does not.  I didn't expect that it would though, I constantly run
SVN versions and they were working under Tiger before I went to Snow Leopard.
I will try this with an ethernet connection tomorrow instead of my wireless.
Based on the Wireshark document there is a chance that ethernet will work after
their fix, even if wireless will not.

There is also the chance that Apple will correct the bug in the next update, which
I *think* should be out soonish.


Tom

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[walts]

I apologize for "shouting" my name.  I had some problems with my mail  
client and when I reinstalled it, it seems to have picked up my user  
name which was all caps.  Both, hopefully, have now been fixed.

FWIW, I am running OS X 10.6.1 which seems to be the latest from Apple.
I'm also using the AirPort exclusively on a fairly new Mac Book Pro.  
It's the AirPort Extreme.

Walt

On Oct 15, 2009, at 11:22 PM, Tom Sellers wrote:

> David Fifield wrote:
>> On Thu, Oct 15, 2009 at 09:49:20PM -0400, SCRIVENS WALTER wrote:
>>> I've been dealing with this from version 5.05 BETA1, and I have  
>>> the same symptoms as Tom.
>>>
>>> I have no problem with nmap version 5.0
>> Tom, does version 5.00 work for you too?
>> David Fifield
>
> No, it does not.  I didn't expect that it would though, I constantly  
> run
> SVN versions and they were working under Tiger before I went to Snow  
> Leopard.
> I will try this with an ethernet connection tomorrow instead of my  
> wireless.
> Based on the Wireshark document there is a chance that ethernet will  
> work after
> their fix, even if wireless will not.
>
> There is also the chance that Apple will correct the bug in the next  
> update, which
> I *think* should be out soonish.
>
>
> Tom
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://SecLists.Org

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[David Fifield]

On Thu, Oct 15, 2009 at 07:10:49PM -0500, Tom Sellers wrote:

> I saw this while going through the TODO file:
>
> o Potential OS X 10.6 problems.  There are two issues reported by the
>   same user which may be related:
>   http://seclists.org/nmap-dev/2009/q3/0936.html,
>   http://seclists.org/nmap-dev/2009/q3/0996.html.  One is that Nmap
>   hangs doing nothing and needs to be killed with Ctrl-C, and the
>   other is that it dies after printing "Initiating UDP Scan".  Another
>   reported the same problem at
>   http://seclists.org/nmap-dev/2009/q3/0990.html, where it dies after
>   the first ARP request is sent.  But Brandon has run Nmap on 10.6
>   without problems.  It is a bit of a mystery. [David]
>
>
> I have this problem on my Snow Leopard system.  Normal users can run
> certain scans, but root cannot.  Even simple scans are affected..
>
> sudo nmap -sP -d9 scanme.nmap.org   chokes here until I kill it:
>
> **********************************************************************
> Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-10-15 19:04 CDT
> The max # of sockets we are using is: 0
> --------------- Timing report ---------------
>   hostgroups: min 1, max 100000
>   rtt-timeouts: init 1000, min 100, max 10000
>   max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
>   parallelism: min 0, max 0
>   max-retries: 10, host-timeout: 0
>   min-rate: 0, max-rate: 0
> ---------------------------------------------
> Initiating Ping Scan at 19:04
> Scanning 64.13.134.52 [4 ports]
> Pcap filter: dst host 192.168.200.77 and (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52)))
> Packet capture filter (device en1): dst host 192.168.200.77 and (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52)))
> SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 echo request (type=8/code=0) ttl=51 id=6159 iplen=28
> SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:443 S ttl=50 id=14485 iplen=44  seq=1618135438 win=3072 <mss 1460>
> SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:80 A ttl=53 id=3056 iplen=40  seq=1618135438 win=2048 ack=3449250024
> SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 Timestamp request (type=13/code=0) ttl=39 id=29241 iplen=40
> **TIMING STATS** (0.0040s): IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay, timeout/srtt/rttvar/
>    Groupstats (1/1 incomplete): 4/*/*/*/*/* 10.00/75/* 1000000/-1/-1
>    64.13.134.52: 4/0/0/4/0/0 10.00/75/0 1000000/-1/-1
> Current sending rates: 3988.04 packets / s, 151545.36 bytes / s.
> Overall sending rates: 3988.04 packets / s, 151545.36 bytes / s.
>
>
> **********************************************************************
>
>
> This appears to be a change in behavior (BUG) introduced in Snow Leopard
> and other projects are running into it as well.
>
> Wireshark has a pretty informative open item:
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3980
>
> Basically it looks like the bpf interfaces are goofed and the only traffic
> you cannot see is that which YOUR machine sent.  In my case, it is over a
> wireless adapter which worked fine pre-upgrade as well as under Windows 7.
>
> I will try digging into this some more, but I wanted to go ahead and throw
> this data out there.

Every online source I've found also seems to indicate that this is an
Apple bug rleated to the permissions of the bpf devices. The libpcap
README.macosx says:

http://github.com/mcr/libpcap/commit/bb8cce59686f4ebba5aeee3073fb9322ec9ef6f9#L0R70
"(NOTE: due to a bug in Snow Leopard, if you change the permissions not
to grant write permission to everybody who should be allowed to capture
traffic, non-root users who cannot open the BPF devices for writing will
not be able to capture outgoing packets.)"

The Wireshark bug report above says
"The workaround is to give the users in question write permission as
well - for example, if "ls -l /dev/bpf*' reports something such as
crw-r-----  1 root  admin   23,   0 Sep  3 18:45 /dev/bpf0
do "sudo chmod g+w /dev/bpf*" so that the admin group gets write
permission as well."

The Wireshark bug report also says that this bug is known by Apple under
the numbers 6944871 and 7210378.

What is the output of "ls -l /dev/bpf*"? Does the problem go away after
changing the permissions with "sudo chmod u+w /dev/bpf*"?

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[David Fifield]

On Thu, Oct 15, 2009 at 09:49:20PM -0400, SCRIVENS WALTER wrote:

> I've been dealing with this from version 5.05 BETA1, and I have the same
> symptoms as Tom.
>
> I have no problem with nmap version 5.0
>
> I have  no problem with Wireshark version 1.2.0 under OS X 10.6.1 once I
> applied the recommended patch, sudo chmod g+w /dev/bpf*
>
> Here is the backtrace from my nmap5.05BETA1:
>
> Reading symbols for shared libraries .++++++.. done
> 0x00007fff8653b364 in read ()
> (gdb) backtrace
> #0  0x00007fff8653b364 in read ()
> #1  0x00000001001635fc in pcap_read_bpf ()
> #2  0x000000010016524b in pcap_next ()
> #3  0x0000000100012e6f in readip_pcap (pd=0x100201900, len=0x7fff5fbfaccc, to_usec=999756, rcvdtime=0x7fff5fbfaca0, linknfo=0x7fff5fbfacd0, validate=true) at tcpip.cc:2330
> #4  0x0000000100036fd7 in waitForResponses (USI=0x100201410) at scan_engine.cc:4414
> #5  0x000000010003a8ff in ultra_scan (Targets=@0x7fff5fbfaf00, ports=0x100201480, scantype=STYPE_UNKNOWN, to=0x1000c97a4) at scan_engine.cc:5280
> #6  0x000000010000cd24 in ~vector [inlined] () at targets.cc:429
> #7  0x000000010000cd24 in ~vector [inlined] () at /usr/include/c++/4.2.1/bits/stl_vector.h:271
> #8  0x000000010000cd24 in massping (hostbatch=0x1, num_hosts=1, ports=0x7fff5fbfc740) at targets.cc:429
> #9  0x000000010000d3a2 in nexthost (hs=0x10081fc00, exclude_group=0x0, ports=0x7fff5fbfc740, pingtype=122) at targets.cc:583
> #10 0x0000000100008613 in nmap_main (argc=4, argv=0x7fff5fbffb78) at nmap.cc:1722
> #11 0x0000000100003bdb in main (argc=4, argv=0x7fff5fbffb78) at main.cc:205
> (gdb)
>
> It is different from Tom's, but I have no idea what I'm looking at :-)

I have a suspicion of where the hang might be occurring. It might happen
where pcap_next is called for an unknown datalink type. Can you try
running the attached patch? Just save it in your nmap working directory
and run

patch -p0 < pcap_datalink_log.diff

Then run a scan using the -d option to see the extra log messages. What
we're looking for are messages along the lines of

pcap_datalink returned unknown datalink type %d
a pcap_next

David Fifield

Index: tcpip.cc
===================================================================
--- tcpip.cc (revision 15886)
+++ tcpip.cc (working copy)
@@ -2289,11 +2289,19 @@
     break;
 #endif
   default:
+    if (o.debugging) {
+      log_write(LOG_PLAIN, "pcap_datalink returned unknown datalink type %d\n",
+        datalink);
+    }
+    if (o.debugging)
+      log_write(LOG_PLAIN, "a pcap_next\n");
     p = (char *) pcap_next(pd, &head);
     if (head.caplen == 0) {
       /* Lets sleep a brief time and try again to increase the chance of seeing
          a real packet ... */
       usleep(500000);
+      if (o.debugging)
+        log_write(LOG_PLAIN, "b pcap_next\n");
       p = (char *) pcap_next(pd, &head);
     }
     if (head.caplen > 100000) {
@@ -2326,8 +2334,11 @@
 
     if (pcap_select(pd, to_usec) == 0)
       timedout = 1;
-    else
+    else {
+      if (o.debugging)
+        log_write(LOG_PLAIN, "c pcap_next\n");
       p = (char *) pcap_next(pd, &head);
+    }
 
     if (p) {
       if (head.caplen <= offset) {

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[walts]

Here's the log.
The pcap_next() call is in line 2 but I have no idea what line 3  
means :-(

Walt
===============================
testcomputer:~ walts$ sudo gdb ./nmap 1624
GNU gdb 6.3.50-20050815 (Apple version gdb-1344) (Fri Jul  3 01:19:56  
UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "x86_64-apple-darwin"..../nmap: No such  
file or directory

/Users/walts/1624: No such file or directory
Attaching to process 1624.
Reading symbols for shared libraries . done
Reading symbols for shared libraries .......... done
0x00007fff838e9364 in read ()
(gdb) backtrace
#0  0x00007fff838e9364 in read ()
#1  0x00000001001635fc in pcap_read_bpf ()
#2  0x000000010016524b in pcap_next ()
#3  0x0000000100012e6f in readip_pcap (pd=0x100201900,  
len=0x7fff5fbfaccc, to_usec=998850, rcvdtime=0x7fff5fbfaca0,  
linknfo=0x7fff5fbfacd0, validate=true) at tcpip.cc:2330
#4  0x0000000100036fd7 in waitForResponses (USI=0x100201410) at  
scan_engine.cc:4414
#5  0x000000010003a8ff in ultra_scan (Targets=@0x7fff5fbfaf00,  
ports=0x100201480, scantype=STYPE_UNKNOWN, to=0x1000c97a4) at  
scan_engine.cc:5280
#6  0x000000010000cd24 in ~vector [inlined] () at targets.cc:429
#7  0x000000010000cd24 in ~vector [inlined] () at /usr/include/c++/
4.2.1/bits/stl_vector.h:271
#8  0x000000010000cd24 in massping (hostbatch=0x1, num_hosts=1,  
ports=0x7fff5fbfc740) at targets.cc:429
#9  0x000000010000d3a2 in nexthost (hs=0x10081fc00, exclude_group=0x0,  
ports=0x7fff5fbfc740, pingtype=122) at targets.cc:583
#10 0x0000000100008613 in nmap_main (argc=4, argv=0x7fff5fbffb78) at  
nmap.cc:1722
#11 0x0000000100003bdb in main (argc=4, argv=0x7fff5fbffb78) at  
main.cc:205
(gdb)

On Oct 23, 2009, at 10:00 AM, David Fifield wrote:

> On Thu, Oct 15, 2009 at 09:49:20PM -0400, SCRIVENS WALTER wrote:
>> I've been dealing with this from version 5.05 BETA1, and I have the  
>> same
>> symptoms as Tom.
>>
>> I have no problem with nmap version 5.0
>>
>> I have  no problem with Wireshark version 1.2.0 under OS X 10.6.1  
>> once I
>> applied the recommended patch, sudo chmod g+w /dev/bpf*
>>
>> Here is the backtrace from my nmap5.05BETA1:
>>
>> Reading symbols for shared libraries .++++++.. done
>> 0x00007fff8653b364 in read ()
>> (gdb) backtrace
>> #0  0x00007fff8653b364 in read ()
>> #1  0x00000001001635fc in pcap_read_bpf ()
>> #2  0x000000010016524b in pcap_next ()
>> #3  0x0000000100012e6f in readip_pcap (pd=0x100201900,  
>> len=0x7fff5fbfaccc, to_usec=999756, rcvdtime=0x7fff5fbfaca0,  
>> linknfo=0x7fff5fbfacd0, validate=true) at tcpip.cc:2330
>> #4  0x0000000100036fd7 in waitForResponses (USI=0x100201410) at  
>> scan_engine.cc:4414
>> #5  0x000000010003a8ff in ultra_scan (Targets=@0x7fff5fbfaf00,  
>> ports=0x100201480, scantype=STYPE_UNKNOWN, to=0x1000c97a4) at  
>> scan_engine.cc:5280
>> #6  0x000000010000cd24 in ~vector [inlined] () at targets.cc:429
>> #7  0x000000010000cd24 in ~vector [inlined] () at /usr/include/c++/
>> 4.2.1/bits/stl_vector.h:271
>> #8  0x000000010000cd24 in massping (hostbatch=0x1, num_hosts=1,  
>> ports=0x7fff5fbfc740) at targets.cc:429
>> #9  0x000000010000d3a2 in nexthost (hs=0x10081fc00,  
>> exclude_group=0x0, ports=0x7fff5fbfc740, pingtype=122) at  
>> targets.cc:583
>> #10 0x0000000100008613 in nmap_main (argc=4, argv=0x7fff5fbffb78)  
>> at nmap.cc:1722
>> #11 0x0000000100003bdb in main (argc=4, argv=0x7fff5fbffb78) at  
>> main.cc:205
>> (gdb)
>>
>> It is different from Tom's, but I have no idea what I'm looking  
>> at :-)
>
> I have a suspicion of where the hang might be occurring. It might  
> happen
> where pcap_next is called for an unknown datalink type. Can you try
> running the attached patch? Just save it in your nmap working  
> directory
> and run
>
> patch -p0 < pcap_datalink_log.diff
>
> Then run a scan using the -d option to see the extra log messages.  
> What
> we're looking for are messages along the lines of
>
> pcap_datalink returned unknown datalink type %d
> a pcap_next
>
> David Fifield
> <
> pcap_datalink_log.diff>_______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[David Fifield]

On Fri, Oct 23, 2009 at 10:47:11AM -0400, Walt Scrivens wrote:
> Here's the log.
> The pcap_next() call is in line 2 but I have no idea what line 3 means
> :-(

Sorry, what I'm looking for here is the output Nmap prints to the
screen, not the GDB backtrace. There are three calls to pcap_next in
readip_pcap, and I want to determine which one of them is hanging.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[walts]

I misunderstood :-(

Here is the terminal output:
=====================
Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-10-23 12:37 EDT
The max # of sockets we are using is: 0
--------------- Timing report ---------------
   hostgroups: min 1, max 100000
   rtt-timeouts: init 1000, min 100, max 10000
   max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
   parallelism: min 0, max 0
   max-retries: 10, host-timeout: 0
   min-rate: 0, max-rate: 0
---------------------------------------------
Warning: Unable to open interface vmnet8 -- skipping it.
Warning: Unable to open interface vmnet1 -- skipping it.
Initiating Ping Scan at 12:37
Scanning 64.13.134.52 [4 ports]
Pcap filter: dst host 192.168.1.144 and (icmp or ((tcp or udp or sctp)  
and (src host 64.13.134.52)))
Packet capture filter (device en1): dst host 192.168.1.144 and (icmp  
or ((tcp or udp or sctp) and (src host 64.13.134.52)))
SENT (0.0100s) ICMP 192.168.1.144 > 64.13.134.52 echo request (type=8/
code=0) ttl=51 id=34354 iplen=28
SENT (0.0100s) TCP 192.168.1.144:34731 > 64.13.134.52:443 S ttl=48  
id=45564 iplen=44  seq=1339274943 win=1024 <mss 1460>
SENT (0.0100s) TCP 192.168.1.144:34731 > 64.13.134.52:80 A ttl=44  
id=20245 iplen=40  seq=1339274943 win=1024 ack=4226847096
SENT (0.0100s) ICMP 192.168.1.144 > 64.13.134.52 Timestamp request  
(type=13/code=0) ttl=40 id=9543 iplen=40
**TIMING STATS** (0.0100s): IP, probes active/freshportsleft/
retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay,  
timeout/srtt/rttvar/
    Groupstats (1/1 incomplete): 4/*/*/*/*/* 10.00/75/* 1000000/-1/-1
    64.13.134.52: 4/0/0/4/0/0 10.00/75/0 1000000/-1/-1
Current sending rates: 8639.31 packets / s, 328293.74 bytes / s.
Overall sending rates: 8639.31 packets / s, 328293.74 bytes / s.
.
.
.
At this point it locks up.


On Oct 23, 2009, at 12:32 PM, David Fifield wrote:

> On Fri, Oct 23, 2009 at 10:47:11AM -0400, Walt Scrivens wrote:
>> Here's the log.
>> The pcap_next() call is in line 2 but I have no idea what line 3  
>> means
>> :-(
>
> Sorry, what I'm looking for here is the output Nmap prints to the
> screen, not the GDB backtrace. There are three calls to pcap_next in
> readip_pcap, and I want to determine which one of them is hanging.
>
> David Fifield
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[David Fifield]

On Fri, Oct 23, 2009 at 12:40:39PM -0400, Walt Scrivens wrote:

> I misunderstood :-(
>
> Here is the terminal output:
> =====================
> Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-10-23 12:37 EDT
> The max # of sockets we are using is: 0
> --------------- Timing report ---------------
>   hostgroups: min 1, max 100000
>   rtt-timeouts: init 1000, min 100, max 10000
>   max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
>   parallelism: min 0, max 0
>   max-retries: 10, host-timeout: 0
>   min-rate: 0, max-rate: 0
> ---------------------------------------------
> Warning: Unable to open interface vmnet8 -- skipping it.
> Warning: Unable to open interface vmnet1 -- skipping it.
> Initiating Ping Scan at 12:37
> Scanning 64.13.134.52 [4 ports]
> Pcap filter: dst host 192.168.1.144 and (icmp or ((tcp or udp or sctp)  
> and (src host 64.13.134.52)))
> Packet capture filter (device en1): dst host 192.168.1.144 and (icmp or
> ((tcp or udp or sctp) and (src host 64.13.134.52)))
> SENT (0.0100s) ICMP 192.168.1.144 > 64.13.134.52 echo request (type=8/
> code=0) ttl=51 id=34354 iplen=28
> SENT (0.0100s) TCP 192.168.1.144:34731 > 64.13.134.52:443 S ttl=48  
> id=45564 iplen=44  seq=1339274943 win=1024 <mss 1460>
> SENT (0.0100s) TCP 192.168.1.144:34731 > 64.13.134.52:80 A ttl=44  
> id=20245 iplen=40  seq=1339274943 win=1024 ack=4226847096
> SENT (0.0100s) ICMP 192.168.1.144 > 64.13.134.52 Timestamp request  
> (type=13/code=0) ttl=40 id=9543 iplen=40
> **TIMING STATS** (0.0100s): IP, probes active/freshportsleft/
> retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay,  
> timeout/srtt/rttvar/
>    Groupstats (1/1 incomplete): 4/*/*/*/*/* 10.00/75/* 1000000/-1/-1
>    64.13.134.52: 4/0/0/4/0/0 10.00/75/0 1000000/-1/-1
> Current sending rates: 8639.31 packets / s, 328293.74 bytes / s.
> Overall sending rates: 8639.31 packets / s, 328293.74 bytes / s.
> .
> .
> .
> At this point it locks up.

Is that with the patch from
http://seclists.org/nmap-dev/2009/q4/att-155/pcap_datalink_log.diff? I
would have expected a "pcap_next" debug line near the end there.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[walts]

Yes, I applied the patch.  It doesn't have to be applied every time I  
run nmap, does it?  I tried applying it again, and it wanted to  
Reverse the patch, so I said No.

Walt

On Oct 23, 2009, at 12:52 PM, David Fifield wrote:

> On Fri, Oct 23, 2009 at 12:40:39PM -0400, Walt Scrivens wrote:
>> I misunderstood :-(
>>
>> Here is the terminal output:
>> =====================
>> Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-10-23 12:37 EDT
>> The max # of sockets we are using is: 0
>> --------------- Timing report ---------------
>>  hostgroups: min 1, max 100000
>>  rtt-timeouts: init 1000, min 100, max 10000
>>  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
>>  parallelism: min 0, max 0
>>  max-retries: 10, host-timeout: 0
>>  min-rate: 0, max-rate: 0
>> ---------------------------------------------
>> Warning: Unable to open interface vmnet8 -- skipping it.
>> Warning: Unable to open interface vmnet1 -- skipping it.
>> Initiating Ping Scan at 12:37
>> Scanning 64.13.134.52 [4 ports]
>> Pcap filter: dst host 192.168.1.144 and (icmp or ((tcp or udp or  
>> sctp)
>> and (src host 64.13.134.52)))
>> Packet capture filter (device en1): dst host 192.168.1.144 and  
>> (icmp or
>> ((tcp or udp or sctp) and (src host 64.13.134.52)))
>> SENT (0.0100s) ICMP 192.168.1.144 > 64.13.134.52 echo request  
>> (type=8/
>> code=0) ttl=51 id=34354 iplen=28
>> SENT (0.0100s) TCP 192.168.1.144:34731 > 64.13.134.52:443 S ttl=48
>> id=45564 iplen=44  seq=1339274943 win=1024 <mss 1460>
>> SENT (0.0100s) TCP 192.168.1.144:34731 > 64.13.134.52:80 A ttl=44
>> id=20245 iplen=40  seq=1339274943 win=1024 ack=4226847096
>> SENT (0.0100s) ICMP 192.168.1.144 > 64.13.134.52 Timestamp request
>> (type=13/code=0) ttl=40 id=9543 iplen=40
>> **TIMING STATS** (0.0100s): IP, probes active/freshportsleft/
>> retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay,
>> timeout/srtt/rttvar/
>>   Groupstats (1/1 incomplete): 4/*/*/*/*/* 10.00/75/* 1000000/-1/-1
>>   64.13.134.52: 4/0/0/4/0/0 10.00/75/0 1000000/-1/-1
>> Current sending rates: 8639.31 packets / s, 328293.74 bytes / s.
>> Overall sending rates: 8639.31 packets / s, 328293.74 bytes / s.
>> .
>> .
>> .
>> At this point it locks up.
>
> Is that with the patch from
> http://seclists.org/nmap-dev/2009/q4/att-155/pcap_datalink_log.diff? I
> would have expected a "pcap_next" debug line near the end there.
>
> David Fifield
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[Tom Sellers]

Walt Scrivens wrote:
> Yes, I applied the patch.  It doesn't have to be applied every time I
> run nmap, does it?  I tried applying it again, and it wanted to
> Reverse the patch, so I said No.
>>
>> Is that with the patch from
>> http://seclists.org/nmap-dev/2009/q4/att-155/pcap_datalink_log.diff? I
>> would have expected a "pcap_next" debug line near the end there.
>>
>> David Fifield
Walt, have you recompiled after installing the patch?

David, my primary machine has been in the shop for a few days
(under warranty!).  It should be out early next week.  After a
fresh OS install will help test this.

I can tell you that my problems persisted even after making
the permissions changes the interfaces.

Tom
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[walts]

OOPS!

I answered David's e-mal with one foot out the door and have been away  
all afternoon.
Here's the output after compiling with the patch:
=========================
Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-10-23 19:41 EDT
The max # of sockets we are using is: 0
--------------- Timing report ---------------
   hostgroups: min 1, max 100000
   rtt-timeouts: init 1000, min 100, max 10000
   max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
   parallelism: min 0, max 0
   max-retries: 10, host-timeout: 0
   min-rate: 0, max-rate: 0
---------------------------------------------
Warning: Unable to open interface vmnet8 -- skipping it.
Warning: Unable to open interface vmnet1 -- skipping it.
Initiating Ping Scan at 19:41
Scanning 64.13.134.52 [4 ports]
Pcap filter: dst host 192.168.1.144 and (icmp or ((tcp or udp or sctp)  
and (src host 64.13.134.52)))
Packet capture filter (device en1): dst host 192.168.1.144 and (icmp  
or ((tcp or udp or sctp) and (src host 64.13.134.52)))
SENT (0.1530s) ICMP 192.168.1.144 > 64.13.134.52 echo request (type=8/
code=0) ttl=49 id=12314 iplen=28
SENT (0.1530s) TCP 192.168.1.144:59705 > 64.13.134.52:443 S ttl=52  
id=20636 iplen=44  seq=4131407077 win=1024 <mss 1460>
SENT (0.1530s) TCP 192.168.1.144:59705 > 64.13.134.52:80 A ttl=59  
id=15689 iplen=40  seq=4131407077 win=4096 ack=2628735480
SENT (0.1530s) ICMP 192.168.1.144 > 64.13.134.52 Timestamp request  
(type=13/code=0) ttl=45 id=48279 iplen=40
**TIMING STATS** (0.1530s): IP, probes active/freshportsleft/
retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay,  
timeout/srtt/rttvar/
    Groupstats (1/1 incomplete): 4/*/*/*/*/* 10.00/75/* 1000000/-1/-1
    64.13.134.52: 4/0/0/4/0/0 10.00/75/0 1000000/-1/-1
Current sending rates: 8810.57 packets / s, 334801.76 bytes / s.
Overall sending rates: 8810.57 packets / s, 334801.76 bytes / s.
c pcap_next

=============================

I hope that means something to you guys!

Walt

On Oct 23, 2009, at 6:18 PM, Tom Sellers wrote:

> Walt Scrivens wrote:
>> Yes, I applied the patch.  It doesn't have to be applied every time I
>> run nmap, does it?  I tried applying it again, and it wanted to
>> Reverse the patch, so I said No.
>>>
>>> Is that with the patch from
>>> http://seclists.org/nmap-dev/2009/q4/att-155/ 
>>> pcap_datalink_log.diff? I
>>> would have expected a "pcap_next" debug line near the end there.
>>>
>>> David Fifield
> Walt, have you recompiled after installing the patch?
>
> David, my primary machine has been in the shop for a few days
> (under warranty!).  It should be out early next week.  After a
> fresh OS install will help test this.
>
> I can tell you that my problems persisted even after making
> the permissions changes the interfaces.
>
> Tom
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[David Fifield]

On Thu, Oct 15, 2009 at 07:10:49PM -0500, Tom Sellers wrote:

> I saw this while going through the TODO file:
>
> o Potential OS X 10.6 problems.  There are two issues reported by the
>   same user which may be related:
>   http://seclists.org/nmap-dev/2009/q3/0936.html,
>   http://seclists.org/nmap-dev/2009/q3/0996.html.  One is that Nmap
>   hangs doing nothing and needs to be killed with Ctrl-C, and the
>   other is that it dies after printing "Initiating UDP Scan".  Another
>   reported the same problem at
>   http://seclists.org/nmap-dev/2009/q3/0990.html, where it dies after
>   the first ARP request is sent.  But Brandon has run Nmap on 10.6
>   without problems.  It is a bit of a mystery. [David]
>
>
> I have this problem on my Snow Leopard system.  Normal users can run
> certain scans, but root cannot.  Even simple scans are affected..
>
> sudo nmap -sP -d9 scanme.nmap.org   chokes here until I kill it:
>
> **********************************************************************
> Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-10-15 19:04 CDT
> The max # of sockets we are using is: 0
> --------------- Timing report ---------------
>   hostgroups: min 1, max 100000
>   rtt-timeouts: init 1000, min 100, max 10000
>   max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
>   parallelism: min 0, max 0
>   max-retries: 10, host-timeout: 0
>   min-rate: 0, max-rate: 0
> ---------------------------------------------
> Initiating Ping Scan at 19:04
> Scanning 64.13.134.52 [4 ports]
> Pcap filter: dst host 192.168.200.77 and (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52)))
> Packet capture filter (device en1): dst host 192.168.200.77 and (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52)))
> SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 echo request (type=8/code=0) ttl=51 id=6159 iplen=28
> SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:443 S ttl=50 id=14485 iplen=44  seq=1618135438 win=3072 <mss 1460>
> SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:80 A ttl=53 id=3056 iplen=40  seq=1618135438 win=2048 ack=3449250024
> SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 Timestamp request (type=13/code=0) ttl=39 id=29241 iplen=40
> **TIMING STATS** (0.0040s): IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay, timeout/srtt/rttvar/
>    Groupstats (1/1 incomplete): 4/*/*/*/*/* 10.00/75/* 1000000/-1/-1
>    64.13.134.52: 4/0/0/4/0/0 10.00/75/0 1000000/-1/-1
> Current sending rates: 3988.04 packets / s, 151545.36 bytes / s.
> Overall sending rates: 3988.04 packets / s, 151545.36 bytes / s.

I can reproduce this now with 10.6 (upgraded from an existing 10.5
installation) and the Xcode that comes with it. However, Nmap runs fine
if I have a tcpdump or Wireshark capture running at the same time. Is it
the same for you? Any ideas why that might be?

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[David Fifield]

On Thu, Nov 05, 2009 at 09:10:51PM -0700, David Fifield wrote:

> On Thu, Oct 15, 2009 at 07:10:49PM -0500, Tom Sellers wrote:
> > sudo nmap -sP -d9 scanme.nmap.org   chokes here until I kill it:
> >
> > **********************************************************************
> > Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-10-15 19:04 CDT
> > The max # of sockets we are using is: 0
> > --------------- Timing report ---------------
> >   hostgroups: min 1, max 100000
> >   rtt-timeouts: init 1000, min 100, max 10000
> >   max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
> >   parallelism: min 0, max 0
> >   max-retries: 10, host-timeout: 0
> >   min-rate: 0, max-rate: 0
> > ---------------------------------------------
> > Initiating Ping Scan at 19:04
> > Scanning 64.13.134.52 [4 ports]
> > Pcap filter: dst host 192.168.200.77 and (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52)))
> > Packet capture filter (device en1): dst host 192.168.200.77 and (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52)))
> > SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 echo request (type=8/code=0) ttl=51 id=6159 iplen=28
> > SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:443 S ttl=50 id=14485 iplen=44  seq=1618135438 win=3072 <mss 1460>
> > SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:80 A ttl=53 id=3056 iplen=40  seq=1618135438 win=2048 ack=3449250024
> > SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 Timestamp request (type=13/code=0) ttl=39 id=29241 iplen=40
> > **TIMING STATS** (0.0040s): IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay, timeout/srtt/rttvar/
> >    Groupstats (1/1 incomplete): 4/*/*/*/*/* 10.00/75/* 1000000/-1/-1
> >    64.13.134.52: 4/0/0/4/0/0 10.00/75/0 1000000/-1/-1
> > Current sending rates: 3988.04 packets / s, 151545.36 bytes / s.
> > Overall sending rates: 3988.04 packets / s, 151545.36 bytes / s.
>
> I can reproduce this now with 10.6 (upgraded from an existing 10.5
> installation) and the Xcode that comes with it. However, Nmap runs fine
> if I have a tcpdump or Wireshark capture running at the same time. Is it
> the same for you? Any ideas why that might be?

I have been looking into this problem, and I think I have found the
cause, or rather causes, both of which appear to be Apple bugs. The
first is that setting timeouts for read events doesn't work unless the
timeout is at least 1000 milliseconds. The second is that opening a
/dev/bpf? device in O_WRONLY mode and binding it to an interface causes
all other listeners on the interface to see only outgoing traffic. I
don't know of a nice quick fix for these problems.

As for the timeout problem, Nmap opens the pcap device like this:

        USI->pd = my_pcap_open_live(Targets[0]->deviceName(), 100, (o.spoofsource)? 1 : 0, pcap_selectable_fd_valid()? 200 : 2);

The last parameter is the timeout. pcap_selectable_fd_valid() is false
on OS X, so we're requesting a timeout of 2 ms. I wrote a small test
program that just reads packets and prints them. The minimum timeout I
found I could use was 1000; 999 or less caused reads to block forever. I
think this is a bug caused by a switch to 64-bit code in OS X 10.6.
Wireshark made a change in their dumpcap program to use a timeout of
1000 rather than 250 on 64-bit Apple plaforms.

http://www.mail-archive.com/wireshark-dev@.../msg15101.html
http://anonsvn.wireshark.org/viewvc/trunk/dumpcap.c?r1=29591&r2=29641

Increasing the timeout to 1000 keeps pcap_next from blocking forever,
but Nmap still doesn't work because of the problem I'll describe next.
Even when that is worked around, waiting up to 1 s for each pcap read is
unacceptable.

The problem with bpf devices. I noticed that --packet-trace was
reporting only outgoing traffic, even if I disabled the BPF filter
entirely. As I noticed above, if I started a tcpdump capture before
starting Nmap, I saw traffic in both directions. But if I started Nmap
first, paused it with ctrl-Z, then started tcpdump second, tcpdump would
see only outgoing traffic!

I isolated the line in Nmap at which this bizarre behavior begins, and
it is when eth_open is called. That function is defined in
libdnet-stripped/src/eth-bsd.c, and does this in part:

        for (i = 0; i < 128; i++) {
                snprintf(file, sizeof(file), "/dev/bpf%d", i);
                e->fd = open(file, O_WRONLY);
                if (e->fd != -1 || errno != EBUSY)
                        break;
        }
        strlcpy(ifr.ifr_name, device, sizeof(ifr.ifr_name));
        if (ioctl(e->fd, BIOCSETIF, (char *)&ifr) < 0)
                return (eth_close(e));

Somehow, whoever first opens a bpf device and binds it to an interface
with BIOCSETIF, controls access for all other users of the interface.
libdnet opens with O_WRONLY because it only intends to use the interface
to send, but in doing so prevents incoming traffic from being read, even
for different bpf devices, and even in different processes! The anomaly
lasts until the last process that has a bpf handle closes it, at which
point it can be opened with different access.

Increasing the timeout to 1000, and changing the access mode to O_RDWR,
allows Nmap to run, albeit slowly.

How to handle this? The O_RDWR change, while ugly, is pretty innocuous.
We use a short timeout for pcap reads on OS X because you can't select
on a pcap file descriptor. However, apparently poll work for pcap
descriptors in 10.6, where it didn't work before. So doing some kind of
configuration detection and using poll when appropriate is an option.
These tests were all with a stock installation of 10.6. I'll try
updating to whatever the latest version is and see if anything is
different.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[walts]

David,
Thanks for sticking with this.  You've done an impressive bit of  
analysis work.  Your explanation is so good that even I begin to  
understand what's going wrong, although I suppose the chances of apple  
ever doing anything about it are slim to none.

Since the problem doesn't happen in the released version 5, the  
problems you've uncovered are specific to 5.05BETA-1.  Do we know why  
those changes were made, and what the impact of reversing them would be?

Walt

On Nov 7, 2009, at 1:01 PM, David Fifield wrote:

> On Thu, Nov 05, 2009 at 09:10:51PM -0700, David Fifield wrote:
>> On Thu, Oct 15, 2009 at 07:10:49PM -0500, Tom Sellers wrote:
>>> sudo nmap -sP -d9 scanme.nmap.org   chokes here until I kill it:
>>>
>>> **********************************************************************
>>> Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-10-15 19:04 CDT
>>> The max # of sockets we are using is: 0
>>> --------------- Timing report ---------------
>>>  hostgroups: min 1, max 100000
>>>  rtt-timeouts: init 1000, min 100, max 10000
>>>  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
>>>  parallelism: min 0, max 0
>>>  max-retries: 10, host-timeout: 0
>>>  min-rate: 0, max-rate: 0
>>> ---------------------------------------------
>>> Initiating Ping Scan at 19:04
>>> Scanning 64.13.134.52 [4 ports]
>>> Pcap filter: dst host 192.168.200.77 and (icmp or ((tcp or udp or  
>>> sctp) and (src host 64.13.134.52)))
>>> Packet capture filter (device en1): dst host 192.168.200.77 and  
>>> (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52)))
>>> SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 echo request  
>>> (type=8/code=0) ttl=51 id=6159 iplen=28
>>> SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:443 S  
>>> ttl=50 id=14485 iplen=44  seq=1618135438 win=3072 <mss 1460>
>>> SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:80 A ttl=53  
>>> id=3056 iplen=40  seq=1618135438 win=2048 ack=3449250024
>>> SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 Timestamp  
>>> request (type=13/code=0) ttl=39 id=29241 iplen=40
>>> **TIMING STATS** (0.0040s): IP, probes active/freshportsleft/
>>> retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay,  
>>> timeout/srtt/rttvar/
>>>   Groupstats (1/1 incomplete): 4/*/*/*/*/* 10.00/75/* 1000000/-1/-1
>>>   64.13.134.52: 4/0/0/4/0/0 10.00/75/0 1000000/-1/-1
>>> Current sending rates: 3988.04 packets / s, 151545.36 bytes / s.
>>> Overall sending rates: 3988.04 packets / s, 151545.36 bytes / s.
>>
>> I can reproduce this now with 10.6 (upgraded from an existing 10.5
>> installation) and the Xcode that comes with it. However, Nmap runs  
>> fine
>> if I have a tcpdump or Wireshark capture running at the same time.  
>> Is it
>> the same for you? Any ideas why that might be?
>
> I have been looking into this problem, and I think I have found the
> cause, or rather causes, both of which appear to be Apple bugs. The
> first is that setting timeouts for read events doesn't work unless the
> timeout is at least 1000 milliseconds. The second is that opening a
> /dev/bpf? device in O_WRONLY mode and binding it to an interface  
> causes
> all other listeners on the interface to see only outgoing traffic. I
> don't know of a nice quick fix for these problems.
>
> As for the timeout problem, Nmap opens the pcap device like this:
>
> USI->pd = my_pcap_open_live(Targets[0]->deviceName(), 100,  
> (o.spoofsource)? 1 : 0, pcap_selectable_fd_valid()? 200 : 2);
>
> The last parameter is the timeout. pcap_selectable_fd_valid() is false
> on OS X, so we're requesting a timeout of 2 ms. I wrote a small test
> program that just reads packets and prints them. The minimum timeout I
> found I could use was 1000; 999 or less caused reads to block  
> forever. I
> think this is a bug caused by a switch to 64-bit code in OS X 10.6.
> Wireshark made a change in their dumpcap program to use a timeout of
> 1000 rather than 250 on 64-bit Apple plaforms.
>
> http://www.mail-archive.com/wireshark-dev@.../msg15101.html
> http://anonsvn.wireshark.org/viewvc/trunk/dumpcap.c?r1=29591&r2=29641
>
> Increasing the timeout to 1000 keeps pcap_next from blocking forever,
> but Nmap still doesn't work because of the problem I'll describe next.
> Even when that is worked around, waiting up to 1 s for each pcap  
> read is
> unacceptable.
>
> The problem with bpf devices. I noticed that --packet-trace was
> reporting only outgoing traffic, even if I disabled the BPF filter
> entirely. As I noticed above, if I started a tcpdump capture before
> starting Nmap, I saw traffic in both directions. But if I started Nmap
> first, paused it with ctrl-Z, then started tcpdump second, tcpdump  
> would
> see only outgoing traffic!
>
> I isolated the line in Nmap at which this bizarre behavior begins, and
> it is when eth_open is called. That function is defined in
> libdnet-stripped/src/eth-bsd.c, and does this in part:
>
> for (i = 0; i < 128; i++) {
> snprintf(file, sizeof(file), "/dev/bpf%d", i);
> e->fd = open(file, O_WRONLY);
> if (e->fd != -1 || errno != EBUSY)
> break;
> }
> strlcpy(ifr.ifr_name, device, sizeof(ifr.ifr_name));
> if (ioctl(e->fd, BIOCSETIF, (char *)&ifr) < 0)
> return (eth_close(e));
>
> Somehow, whoever first opens a bpf device and binds it to an interface
> with BIOCSETIF, controls access for all other users of the interface.
> libdnet opens with O_WRONLY because it only intends to use the  
> interface
> to send, but in doing so prevents incoming traffic from being read,  
> even
> for different bpf devices, and even in different processes! The  
> anomaly
> lasts until the last process that has a bpf handle closes it, at which
> point it can be opened with different access.
>
> Increasing the timeout to 1000, and changing the access mode to  
> O_RDWR,
> allows Nmap to run, albeit slowly.
>
> How to handle this? The O_RDWR change, while ugly, is pretty  
> innocuous.
> We use a short timeout for pcap reads on OS X because you can't select
> on a pcap file descriptor. However, apparently poll work for pcap
> descriptors in 10.6, where it didn't work before. So doing some kind  
> of
> configuration detection and using poll when appropriate is an option.
> These tests were all with a stock installation of 10.6. I'll try
> updating to whatever the latest version is and see if anything is
> different.
>
> David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[David Fifield]

On Sat, Nov 07, 2009 at 02:57:29PM -0500, Walt Scrivens wrote:
> David,
> Thanks for sticking with this.  You've done an impressive bit of  
> analysis work.  Your explanation is so good that even I begin to  
> understand what's going wrong, although I suppose the chances of apple  
> ever doing anything about it are slim to none.
>
> Since the problem doesn't happen in the released version 5, the problems
> you've uncovered are specific to 5.05BETA-1.  Do we know why those
> changes were made, and what the impact of reversing them would be?

I think it's because the release I made on 10.5 was compiled as a 32-bit
executable, and the default compiler target on 10.6 is 64-bit, but I
haven't tested that yet. We could, of course, build the next release as
32-bit, but that doesn't help the people who build from source unless we
make it automatic in the build system.

For what it's worth, I ran a copy of Nmap that I had built on 10.5 and
still had installed after upgrading to 10.6. It didn't have the blocking
forever problem, but it still couldn't read incoming packets unless I
had a concurrent tcpdump running.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/