Awesome - just when I solve the issue of VMWare breaking nmap on OS X, Parallels comes along and does it again. The error is slightly different, however, so the root cause of the problem is likely somewhat different as well.

Starting Nmap 4.20 ( http://insecure.org ) at 2007-06-14 15:07 CDT getinterfaces: Failed to obtain MAC address for ethernet interface (fw0) QUITTING!

Thus far, I’ve tried disabling the fw0, en2 and en3 interfaces, with no luck. If I bring down fw0, though (sudo ifconfig fw0 down), I get a different error message similar to the VMWare one.

Starting Nmap 4.20 ( http://insecure.org ) at 2007-06-14 15:11 CDT getinterfaces: Failed to open ethernet interface (fw0). A possible cause on BSD operating systems is running out of BPF devices (see http://seclists.org/lists/nmap-dev/2006/Jan-Mar/0014.html). QUITTING!

It seems there’s been a similar problem with Cisco’s VPN software, but the suggested remediation doesn’t work for nmap. I filed a bug report, as I’m sure many others have, so hopefully it will be addressed in a recent update. If I come across a solution, I’ll update this entry…but until then, the only way I can use nmap is by uninstalling Parallels.

Update! After some more detailed information from the Parallels Team, I discovered a way to run nmap successfully. I thought I had tried this approach before, but apparently not. Removing the interface with a <strong>sudo ifconfig fw0 remove</strong> prior to executing nmap seems to allow nmap to run successfully. I seem to have to do this every time as an ip address gets re-assigned to the interface, but it does appear to work!

Update (07/26/2007) The most recent build of Parallels (4560) appears to have fixed the issue metioned above, but another one has manifested itself. Scanning a specific host was able to complete succesfully, but when scanning a network where dead hosts existed would result in a nexthost: failed to determine route error. Specifying the proper interface using the -e parameter seems to address the issue.