Nmap stops working after upgrade to 3.0

Discussion in 'General Questions' started by bkwhite, Jun 18, 2007.

  1. Quuxster

    Quuxster

    Messages:
    7
    I have the same issues as mentioned above. After the "downgrade" to version 3.0 at least nmap does not work properly anymore. The only "workaround" I have found right now is to completely remove parallels 3.0 from the system. then my normal tools work again. After reinstall (but before scanning one of the virtual servers) everything works just fine... :confused:

    This is a MAJOR issue (I guess for more researchers) and I am supprised that there is still no workaround (or better still a correct implementation) available from Parallels support. If this issue is not fixed in the next couple of days I guess I will have to switch to vmware and NEVER look back... :(

    Ciao,
    Quuxster.
     
    Last edited: Jul 7, 2007
  2. bkwhite

    bkwhite

    Messages:
    12
    No response yet from support. (of course I'm hoping that my email filters didn't grab it) I'm going to downgrade to 2.5
     
  3. bkwhite

    bkwhite

    Messages:
    12
    re-graded to build 3214 and nmap works fine.
     
  4. serv

    serv Parallels Developers

    Messages:
    782
    Re Nmap behaviour:

    Nmap 4.20 message about BPF device not available is misleading. Nmap is trying to bind BPF device to fw0 interface upon detecting that fw0 have IPv4 address. What nmap fails to check is whether fw0 is actually UP. If fw0 is down BIOCSETIF ioctl fails with appropriate error (interface is down) but the error code is not checked by nmap and the failure reported as BPF problem. If fw0 is UP nmap will complain that it's unable to obtain fw0 MAC address which is expected since fw0 is not an ethernet device. In both cases nmap ceases to function.

    Why fw0 has IPv4 address configured is another matter. Parallels Transporter is configuring it to provide its service over firewire connection. Connectiong two Macs via firewire will also assign address to fw0. In either case nmap will fail. BTW, Cisco VPN appears to be affected by this fw0 syndrome too.

    Parallels Desktop 3.0 update will be changed not to assign fw0 address early, eliminating the problem in most cases. Complete solution involves changes to nmap, please contact nmap developers for this.
     
    Last edited: Jul 10, 2007
  5. dcash

    dcash

    Messages:
    3
    In light of this detailed information (thanks Parallels Team!) I decided to try something I thought I had tried before:

    Hehe, that's my iPhone. ;-) But looks like removing the interface works.

    However, one quirk is that anytime I want to perform the scan I have to remove the interface immediately before executing nmap or I get the BPF errors again.
     
    Last edited: Jul 10, 2007
  6. bkwhite

    bkwhite

    Messages:
    12
    Thanks serv and dcash. What is confusing is, for me, is what changed between 2.5 and 3.0 of Parallels, that caused the same install of nmap not to work, and how that makes it a nmap problem.

    But I am happy that nmap and cisco VPN will work after the update.

    A sincere thank you
     
  7. mtyrrell

    mtyrrell

    Messages:
    1
    this got me too.

    This bug has frustrated me as well. I've worked around it by creating a debian vm and using nmap from there. Kind of a pain, though.

    Any idea when we'll see the update to parallels 3.0 to address this binding issue?

    Thanks,

    -m
     
  8. dkp

    dkp

    Messages:
    1,412
    NMap is at fault for not properly understanding the state of the interface. The problem does not exist here so I can't test it - the nmap I built works fine. However it is useful to know that the same situation happens with nmap 4.20 in Fusion, too, and is discussed on their BBS.

    dp
     
  9. bkwhite

    bkwhite

    Messages:
    12
    Thx DKP. I wish my build of nmap would have worked. :)

    I guess I still wonder what changed or feature was added between 2.5 and 3.0 to make nmap stop working. Anxiously awaiting the version 3.0 update.
     
  10. Jon Richardson

    Jon Richardson

    Messages:
    23
    Resolved?

    I have been following this thread with interest since I, too, have been plagued with the nmap error others have reported here.

    Based on a few "clues" from previous posts I decided to remove the Parallels Transporter folder from /Library/Startup Items. Guess what? No further problems with nmap, or fw0 having a self-assigned IP address!

    It may not be a "fix", but it's a good enough workaround for me as long as I'm not using Transporter.

    Anyone else care to try this?

    Jon
     
  11. bkwhite

    bkwhite

    Messages:
    12
    Initial test result: removing trasporter from startupitems seemed to do the trick for me.

    Thanks Jon.
     
  12. cybercrypt13

    cybercrypt13

    Messages:
    13
    Jon, what exactly are you doing? I went and removed the /Library/Startup Items/Parallels Transporter folder from my system like you suggest and now Parallels won't run at all. Did you just swap one problem for another?

    glenn
     
  13. cybercrypt13

    cybercrypt13

    Messages:
    13
    And I didn't mention it but obviously I am interested in a fix as well. Does Parallels actually have a support department? I sent them an email earlier but never heard back from them.

    Thanks,

    glenn
     
  14. jasonw

    jasonw

    Messages:
    90
    Is this fixed in #4560?

    I haven't gathered the summoned the courage required to install it yet. I'd prefer to keep my machine working. The "ifconfig fw0 remove" workaround is sufficient for me.
     
  15. cybercrypt13

    cybercrypt13

    Messages:
    13

    Could you explain what that work around is? I'm new to Mac so trying to get up to speed with all this stuff.

    Thanks,

    glenn
     
  16. cybercrypt13

    cybercrypt13

    Messages:
    13
    Nevermind, I figured it out.

    That got me going too.

    Thanks,

    glenn
     
  17. Jon Richardson

    Jon Richardson

    Messages:
    23
    I'm pleased to read that you're ok now, but just for the record here's exactly what I did:

    1. Copy the folder /Library/Startup Items/Parallels Transporter and saved it in somewhere in my Home folder.

    2. Deleted the Parallels Transporter folder from /Library/Startup Items (need admin privileges for this, of course).

    3. Re-started my Mac.

    This resolved the problem and nmap works, Parallels works, and the incorrect settings for "fw0" no longer occur. Just can't use Transporter. My feeling is that if I copied the folder back again and rebooted then Transporter would work again, but I haven't tested that.

    This is all done on MacBook Pro - OSX 10.4.10 with Paralles 4128

    Jon
     
  18. bkwhite

    bkwhite

    Messages:
    12
    nmap seems to work fine after 4560 upgrade

    and Parallels Transporter is back in the startupitems folder.

    Now I've never used the transporter.

    So thanks Parallels, Jon, dkp and everyone else who gave advice.

    bryan
     
  19. Quuxster

    Quuxster

    Messages:
    7
    nmap still not working after upgrade to build 4560

    After installing build 4560 and recompiling nmap 4.20 I still encounter problems. When scanning remote hosts (ie. not on the same LAN) nmap can no longer determine the correct route:

    # nmap -sS -v -sR -O -P0 XXX.XXXX.XXX

    Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-19 11:25 CEST
    nexthost: failed to determine route to AAA.BBB.CCC.DDD
    QUITTING!

    Name resolution works flawlessly (XXX.XXXX.XXX is hostname; AAA.BBB.CCC.DDD is correct IP-address).

    Removing the ParallelsTransporter directory (and reboot) doesn't change the behaviour.

    After uninstalling Parallels nmap works again flawlessly!!!

    Confused!
    Quuxster.
     
    Last edited: Jul 19, 2007
  20. jasonw

    jasonw

    Messages:
    90
    I had the same issue too when trying to scan a host not on the local subnet. The workaround is to specify the interface to use (i.e. -e en1 if using wireless).
     

Share This Page