|
Bugzilla – Full Text Bug Listing |
| Summary: | nmap stealth scanning very slow | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Andreas Klein <asklein> |
| Component: | Other | Assignee: | Hendrik Vogelsang <hvogel> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | dmueller, vetter |
| Version: | Beta 1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
strace
hwinfo IBM R50p log from nmap --packet_trace -oN nmap.log pothole nmap rpm package (i586) nmap rpm package (x86_64) |
||
|
Description
Andreas Klein
2005-08-12 08:57:24 UTC
Created attachment 45863 [details]
strace
can you please try with beta2, there nmap is build against the system libpcap. It doesn't segfault, but there are still errors. On i386: pluto:~ # nmap baul Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-08-22 12:32 CEST (nothing happens) On x86-64: wpyc022:~ # nmap baul Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-08-22 12:39 CEST Failed to resolve given hostname/IP: baul. Note that you can't use '/mask' AND '[1-4,7,100-]' style IP ranges WARNING: No targets were specified, so 0 hosts scanned. Nmap finished: 0 IP addresses (0 hosts up) scanned in 0.022 seconds This is not true, baul resolves without problems: wpyc022:~ # ping baul PING wpyc051.physik.uni-wuerzburg.de (132.187.42.51) 56(84) bytes of data. 64 bytes from 132.187.42.51: icmp_seq=1 ttl=64 time=7.09 ms hm i cant reproduce. whats the output of rpm -q --changelog nmap | head Ok, I think I found the difference. As user: nmap baul and nmap www works As root: nmao baul does not work, nmap www works. So the problem depends on user and host. You can try baul.physik.uni-wuerzburg.de and www.physik.uni-wuerzburg.de Both machines can be nmapped from SuSE 9.3 without problems. pluto:~ # rpm -q --changelog nmap | head * Tue Aug 16 2005 - mmj@suse.de - Don't strip binaries * Tue Aug 09 2005 - hvogel@suse.de - Build against system libpcap/libpcre to avoid libpcap bugs [Bug #98249] * Wed Mar 23 2005 - sbrabec@suse.cz The problem is the scan method, user is default connect and root default to stealth. nmap -sT <host> will also work as root. this smells like the checksum error again. Adding dirk/ak the old bug was during 9.0 times Bug #suse32826 network card with hardware checksumming yes/no ? the old fix was fixing a clobber in kernel asm code.. searching Network card is intel gigabit (IBM R50p). I will attach hwinfo. Created attachment 47364 [details]
hwinfo IBM R50p
scanning works for me, just extremely slow. there is a huge lag.. not sure why. anyway, the checksums are correct, this doesn't seem to be the same bug like suse 9.0. also the patch is still in our tree http://linux.bkbits.net:8080/linux-2.6/diffs/include/asm-i386/checksum.h%401.9?nav=index.html| src/.|src/include|src/include/asm-i386|hist/include/asm-i386/checksum.h andreas: I happen to have a r50p as well. I scan from r50p to another machine with 3c59x card. interestingly enough, the other direction (scanning the r50p from the 3com card) works just great. now thats a funny bug. wtf. looking You might try to turn off TSO with ethtool. TSO doesn't report the correct checksum in packet sockets because the header is only generated by the NIC. It's probably a dup of #105539 The TSO implementation in 10.0 is very different from SLES9, but this issue shouldn't have changed. IMHO it's a nmap bug - it shouldn't do broken PF_PACKET hacks like this. Even funnier: The problem does not exist, when nmapping machines on a different subnet. disabling sg/tso/rx/tx has no effect here also not. more weirdness: running something like tcpdump/iptraf on the device while scanning makes it work... ak can you have a look at g179? i can reproduce it there without a problem with tso set to off. Created attachment 47376 [details]
log from nmap --packet_trace -oN nmap.log pothole
Comment on attachment 45863 [details]
strace
Using text/plain for these is much appreciated :-)
For me, it hangs indefinitely, and the reason is this: 1124891816.149293 setsockopt(5, SOL_SOCKET, SO_ATTACH_FILTER, "&\0h0\340Z\r\10", 8) = 0 1124891816.149365 fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR) 1124891816.149425 fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 1124891816.149487 getsockopt(5, SOL_SOCKET, SO_RCVBUF, [113664], [4]) = 0 1124891816.149551 read(5, 0xbfff31dc, 1024) = -1 EAGAIN (Resource temporarily unavailable) 1124891816.149613 fcntl64(5, F_SETFL, O_RDWR) = 0 ... 1124891816.288150 recvfrom(5, Note how it sets the socket to blocking, and calls recvfrom unconditionally. The reason it works with iptraf enabled is that promisc mode allows the filter to "see" more icmp packets. Looks like an application bug to me. Oh, just running "ping" in a separate window allows the scan to proceed as well. looks like its the system pcre against the internal pcre please everybody try these packages (for beta2) Created attachment 47429 [details]
nmap rpm package (i586)
Created attachment 47430 [details]
nmap rpm package (x86_64)
the only thing i see that does not work now is nmap -sT as user without -e ethN or -S <ip> on x86_64 that is forget my last 2 comments. that was bogus On x86-64 the resolver problem still exists. Sometines it works, sometimes not. wpyc022:/tmp # nmap wpyc018 Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-08-24 18:11 CEST Failed to resolve given hostname/IP: wpyc018. Note that you can't use '/mask' AND '[1-4,7,100-]' style IP ranges WARNING: No targets were specified, so 0 hosts scanned. Nmap finished: 0 IP addresses (0 hosts up) scanned in 0.011 seconds wpyc022:/tmp # nmap wpyc018 Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-08-24 18:11 CEST Interesting ports on wpyc018.physik.uni-wuerzburg.de (132.187.42.18): (The 1660 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind 514/tcp open shell MAC Address: 00:E0:81:2C:90:82 (Tyan Computer) Nmap finished: 1 IP address (1 host up) scanned in 0.456 seconds are you absolutely sure that these are not DNS problems? The 32bit and the 64bit machine use the same name-server and I only see the problem on the 64bit machine. ok that still leaves 10²³ other things that are different. can you try something like for i in `seq 0 100`; do dig -x somehost; done or whatever to be sure? Is everything else resolving fine? I did: for i in `seq 1 44`; do ping -c 1 wpyc`printf "%03d" $i`; done directly after that all machines showed up in arp with their name. After some time, some machines show up with the ip-adress. The machines not resolving change from second to second. So this problem is not nmap specific. asklein@wpyc022:~/bonnie> /sbin/arp Address HWtype HWaddress Flags Mask Iface wpyc001.physik.uni-wuer ether 00:E0:81:2C:18:96 C eth0 wpyc045.physik.uni-wuer ether 00:E0:81:27:60:5A C eth0 wswi41-pa.physik.uni-wu ether 00:D0:95:54:DD:D7 C eth0 wpyc013.physik.uni-wuer ether 00:E0:81:2C:90:F5 C eth0 wpyc018.physik.uni-wuer ether 00:E0:81:2C:90:82 C eth0 wpyc014.physik.uni-wuer ether 00:E0:81:2C:90:18 C eth0 wpyc027.physik.uni-wuer ether 00:E0:81:2C:90:37 C eth0 wpyc037.physik.uni-wuer ether 00:E0:81:2C:90:43 C eth0 wpyc025.physik.uni-wuer ether 00:E0:81:2C:18:82 C eth0 wpyc011.physik.uni-wuer ether 00:E0:81:2C:90:3C C eth0 wpyc010.physik.uni-wuer ether 00:E0:81:2C:90:A5 C eth0 wpyc007.physik.uni-wuer ether 00:E0:81:2B:86:08 C eth0 wpyc028.physik.uni-wuer ether 00:E0:81:2C:18:7A C eth0 wpyc019.physik.uni-wuer ether 00:E0:81:2B:DA:03 C eth0 wpyc031.physik.uni-wuer ether 00:E0:81:2C:90:47 C eth0 wpyc017.physik.uni-wuer ether 00:E0:81:2A:8F:48 C eth0 wpyc029.physik.uni-wuer ether 00:E0:81:2C:90:6A C eth0 wpyc039.physik.uni-wuer ether 00:E0:81:2B:E3:FE C eth0 wpyc035.physik.uni-wuer ether 00:E0:81:2C:90:21 C eth0 wpyc032.physik.uni-wuer ether 00:E0:81:2C:90:77 C eth0 wpyc033.physik.uni-wuer ether 00:E0:81:2C:90:80 C eth0 wpyc049.physik.uni-wuer ether 00:04:23:AC:44:AC C eth0 wpyc003.physik.uni-wuer ether 00:E0:81:2B:DA:21 C eth0 wpyc002.physik.uni-wuer ether 00:E0:81:2C:18:98 C eth0 wpyc024.physik.uni-wuer ether 00:E0:81:2C:18:97 C eth0 wpyc006.physik.uni-wuer ether 00:E0:81:2B:86:07 C eth0 wpyc038.physik.uni-wuer ether 00:E0:81:2C:90:FB C eth0 wpyc041.physik.uni-wuer ether 00:E0:81:29:1B:2D C eth0 wpyc034.physik.uni-wuer ether 00:E0:81:2B:BA:04 C eth0 wpyc005.physik.uni-wuer ether 00:E0:81:2C:18:2D C eth0 wpyc030.physik.uni-wuer ether 00:E0:81:2C:90:DD C eth0 wpyc042.physik.uni-wuer ether 00:E0:81:27:90:83 C eth0 wpyc021.physik.uni-wuer ether 00:E0:81:2C:90:20 C eth0 wpyc026.physik.uni-wuer ether 00:E0:81:2C:90:45 C eth0 wpyc020.physik.uni-wuer ether 00:E0:81:2C:90:FC C eth0 wpyc044.physik.uni-wuer ether 00:E0:81:27:91:0B C eth0 wpyc043.physik.uni-wuer ether 00:E0:81:27:91:0A C eth0 wpyc009.physik.uni-wuer ether 00:E0:81:2C:90:4A C eth0 wpyc023.physik.uni-wuer ether 00:E0:81:2C:90:7D C eth0 wpyc015.physik.uni-wuer ether 00:E0:81:2B:86:05 C eth0 wpyc040.physik.uni-wuer ether 00:E0:81:2B:BA:03 C eth0 wpyc012.physik.uni-wuer ether 00:E0:81:2C:90:EE C eth0 wpyc016.physik.uni-wuer ether 00:E0:81:2B:BA:22 C eth0 wpyc008.physik.uni-wuer ether 00:E0:81:2C:90:FD C eth0 wpyc004.physik.uni-wuer ether 00:E0:81:2C:18:86 C eth0 wpyc036.physik.uni-wuer ether 00:E0:81:2C:18:83 C eth0 asklein@wpyc022:~/bonnie> /sbin/arp Address HWtype HWaddress Flags Mask Iface 132.187.42.1 ether 00:E0:81:2C:18:96 C eth0 wpyc045.physik.uni-wuer ether 00:E0:81:27:60:5A C eth0 wswi41-pa.physik.uni-wu ether 00:D0:95:54:DD:D7 C eth0 wpyc013.physik.uni-wuer ether 00:E0:81:2C:90:F5 C eth0 wpyc018.physik.uni-wuer ether 00:E0:81:2C:90:82 C eth0 wpyc014.physik.uni-wuer ether 00:E0:81:2C:90:18 C eth0 wpyc027.physik.uni-wuer ether 00:E0:81:2C:90:37 C eth0 wpyc037.physik.uni-wuer ether 00:E0:81:2C:90:43 C eth0 wpyc025.physik.uni-wuer ether 00:E0:81:2C:18:82 C eth0 wpyc011.physik.uni-wuer ether 00:E0:81:2C:90:3C C eth0 wpyc010.physik.uni-wuer ether 00:E0:81:2C:90:A5 C eth0 wpyc007.physik.uni-wuer ether 00:E0:81:2B:86:08 C eth0 wpyc028.physik.uni-wuer ether 00:E0:81:2C:18:7A C eth0 wpyc019.physik.uni-wuer ether 00:E0:81:2B:DA:03 C eth0 wpyc031.physik.uni-wuer ether 00:E0:81:2C:90:47 C eth0 132.187.42.17 ether 00:E0:81:2A:8F:48 C eth0 wpyc029.physik.uni-wuer ether 00:E0:81:2C:90:6A C eth0 wpyc039.physik.uni-wuer ether 00:E0:81:2B:E3:FE C eth0 wpyc035.physik.uni-wuer ether 00:E0:81:2C:90:21 C eth0 wpyc032.physik.uni-wuer ether 00:E0:81:2C:90:77 C eth0 wpyc033.physik.uni-wuer ether 00:E0:81:2C:90:80 C eth0 wpyc049.physik.uni-wuer ether 00:04:23:AC:44:AC C eth0 wpyc003.physik.uni-wuer ether 00:E0:81:2B:DA:21 C eth0 wpyc002.physik.uni-wuer ether 00:E0:81:2C:18:98 C eth0 wpyc024.physik.uni-wuer ether 00:E0:81:2C:18:97 C eth0 wpyc006.physik.uni-wuer ether 00:E0:81:2B:86:07 C eth0 wpyc038.physik.uni-wuer ether 00:E0:81:2C:90:FB C eth0 wpyc041.physik.uni-wuer ether 00:E0:81:29:1B:2D C eth0 wpyc034.physik.uni-wuer ether 00:E0:81:2B:BA:04 C eth0 wpyc005.physik.uni-wuer ether 00:E0:81:2C:18:2D C eth0 wpyc030.physik.uni-wuer ether 00:E0:81:2C:90:DD C eth0 wpyc042.physik.uni-wuer ether 00:E0:81:27:90:83 C eth0 wpyc021.physik.uni-wuer ether 00:E0:81:2C:90:20 C eth0 wpyc026.physik.uni-wuer ether 00:E0:81:2C:90:45 C eth0 wpyc020.physik.uni-wuer ether 00:E0:81:2C:90:FC C eth0 wpyc044.physik.uni-wuer ether 00:E0:81:27:91:0B C eth0 wpyc043.physik.uni-wuer ether 00:E0:81:27:91:0A C eth0 wpyc009.physik.uni-wuer ether 00:E0:81:2C:90:4A C eth0 wpyc023.physik.uni-wuer ether 00:E0:81:2C:90:7D C eth0 wpyc015.physik.uni-wuer ether 00:E0:81:2B:86:05 C eth0 wpyc040.physik.uni-wuer ether 00:E0:81:2B:BA:03 C eth0 wpyc012.physik.uni-wuer ether 00:E0:81:2C:90:EE C eth0 wpyc016.physik.uni-wuer ether 00:E0:81:2B:BA:22 C eth0 wpyc008.physik.uni-wuer ether 00:E0:81:2C:90:FD C eth0 132.187.42.4 ether 00:E0:81:2C:18:86 C eth0 wpyc036.physik.uni-wuer ether 00:E0:81:2C:18:83 C eth0 please open another bugreport for this. im closing this one as fixed |