After several trials, tribulations and reading in this forum I finally got the nmap-3.48-with-sql0.0.0.3 to compile. I have a problem, a comment and 2 questions. The comment is, wow - thanks - this is a great idea!
Question one is - Why does it require me to compile nmapfe?
Question two is - Are you planning on updating this to the current version of nmap? V3.7 has some intense speed improvements over previous versions. I tried applying the patches and they wouldn't go, I'm not a programmer otherwise I'd be busy hacking it right now.
My problem is that nmap will run fine without the --mysql switch but when I use it I get the following output:
_______________
linux:~ # nmap --mysql -v -sT -p1-65535 172.16.31.0/24
Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2004-09-16 20:44 PDT
Host 172.16.31.0 seems to be a subnet broadcast address (returned 5 extra pings). Skipping host.
Host 172.16.31.1 appears to be up ... good.
Initiating Connect() Scan against 172.16.31.1 at 20:44
Adding open port 5431/tcp
Adding open port 443/tcp
Adding open port 80/tcp
The Connect() Scan took 49 seconds to scan 65535 ports.
Interesting ports on 172.16.31.1:
(The 65532 ports scanned but not shown below are in state: closed)
caught SIGSEGV signal, cleaning up
Aborted
__________________________
Some data did get written to the database, so I'm pretty sure the dbase is ok and that access.sql is setup OK too. The tables written to were portstat, runlist, scanners, and targets. The portstat table only had 2 ports listed in it 80 and 443.
My system may be a little unique, but it shouldn't be causing any issues (it hasn't with anything else), I am testing this in a VmWare VM where the host O/S is 64 bit suse 9.1 running on an AMD64 3200+ and the guest is 32 bit suse 9.1. The primary reason for doing it this way is that when I'm just trying stuff out, I can take snapshots and discard etc... I also tend to run into fewer compile issues (like I said, I'm no programmer :-)
Let me know if there's anything I can do to get more detail for you.
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have compiled and run successfully now on my AMD64 system without vmware... must be something strange in vmware, or possibly the mysql config in that vm. See the other thread "How To Compile and Run on 64 bit SuSE 9.1 on AMD64".
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
After several trials, tribulations and reading in this forum I finally got the nmap-3.48-with-sql0.0.0.3 to compile. I have a problem, a comment and 2 questions. The comment is, wow - thanks - this is a great idea!
Question one is - Why does it require me to compile nmapfe?
Question two is - Are you planning on updating this to the current version of nmap? V3.7 has some intense speed improvements over previous versions. I tried applying the patches and they wouldn't go, I'm not a programmer otherwise I'd be busy hacking it right now.
My problem is that nmap will run fine without the --mysql switch but when I use it I get the following output:
_______________
linux:~ # nmap --mysql -v -sT -p1-65535 172.16.31.0/24
Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2004-09-16 20:44 PDT
Host 172.16.31.0 seems to be a subnet broadcast address (returned 5 extra pings). Skipping host.
Host 172.16.31.1 appears to be up ... good.
Initiating Connect() Scan against 172.16.31.1 at 20:44
Adding open port 5431/tcp
Adding open port 443/tcp
Adding open port 80/tcp
The Connect() Scan took 49 seconds to scan 65535 ports.
Interesting ports on 172.16.31.1:
(The 65532 ports scanned but not shown below are in state: closed)
caught SIGSEGV signal, cleaning up
Aborted
__________________________
Some data did get written to the database, so I'm pretty sure the dbase is ok and that access.sql is setup OK too. The tables written to were portstat, runlist, scanners, and targets. The portstat table only had 2 ports listed in it 80 and 443.
My system may be a little unique, but it shouldn't be causing any issues (it hasn't with anything else), I am testing this in a VmWare VM where the host O/S is 64 bit suse 9.1 running on an AMD64 3200+ and the guest is 32 bit suse 9.1. The primary reason for doing it this way is that when I'm just trying stuff out, I can take snapshots and discard etc... I also tend to run into fewer compile issues (like I said, I'm no programmer :-)
Let me know if there's anything I can do to get more detail for you.
Paul
I have compiled and run successfully now on my AMD64 system without vmware... must be something strange in vmware, or possibly the mysql config in that vm. See the other thread "How To Compile and Run on 64 bit SuSE 9.1 on AMD64".
Paul