Bugzilla – Bug 115846
nmap does not work properly because of a kernel "bug" that break libpcap
Last modified: 2005-09-14 16:33:37 UTC
All systems I try to scan via nmap end up with : Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 but specifying -P0 (which disables the different pings to see if host is up) does not work too. nmap does not seem to see the incoming packages. tcpdum shows that packets go out, and that responses come in on this interface. I have downloaded and compiled the recently released 3.90 version, no change here. I think its not a problem directly related to nmap, but to something else, maybe kernel 2.6.13 is the reason ?
additiona: I had an older kernel 2.6.12.1 available, booted it up and nmap worked. does not work with 2.6.13 though
i cant reproduce that in any way. please provide the output of nmap -d <host to scan>
Unfortunately Im currently not able to do that, since I now have another kind of internet connection, and there it works fine. Its now an ethernet connection thats routed through local network into the internet. Previously it was a pppoe device (called dsl2) that produced problems. I have talked to a debian user, and he experiences currently the same problems with his ipsec ppp0 device, but *only* when running kernel 2.6.13. So I think its a kernel problem, but since I currently dont have access to a DSL system for the next two weeks I cannot test it anymore. Btw. I use the vanilla 2.6.13 kernel, maybe its fixed in the suse kernel patches ? anyways, I cannot run the suse kernel on my laptop, acpi problems...
Can reproduce here with a ISDN sync ppp dialup connection on RC1. A connection via local LAN does not show the bug. Also only user root is affected, as normal user it work. I also tested Beta1, here nmap segfaults as root, but work also as user.
Yes, same on RC1 here too (just upgraded). As a normal user nmap does not use raw sockets, while as root it uses them. btw there is now nmap 3.90 with lots of new features and updated fingerprints etc., I think it should make it into the final 10.0 I really think its a kernel & raw sockets thing, since it works fine on 2.6.12.x here and at lots of other systems as well. Can you verify with tcpdump too that packets go out and come in on the ppp interface ? maybe a strace shows if nmap gets something or not...
I have had access to a system connected via ppp (over pptp) and did an strace. nmap first sets a kernel filter via setsockopt SO_ATTACH_FILTER, then does a sendto of the packets, and then waits on the sockeet via select... this times out, though the data arrives at the host. When the user is non-root, there is no such option set, I dont know what when its an ethernet device. Maybe the interpretation of the LSF code has changed in 2.6.13 so that it now filters away those packets errenously ?
*update* I just saw in the 2.6.13.1 release this commit: ommit a49567a4dbfd414f19e5bf828a4b2c540f164ea8 Author: Herbert Xu <herbert@gondor.apana.org.au> Date: Mon Sep 5 18:47:10 2005 -0700 [PATCH] 2.6.13 breaks libpcap (and tcpdump) [NET]: 2.6.13 breaks libpcap (and tcpdump) Patrick McHardy says: Never mind, I got it, we never fall through to the second switch statement anymore. I think we could simply break when load_pointer returns NULL. The switch statement will fall through to the default case and return 0 for all cases but 0 > k >= SKF_AD_OFF. and I think maybe this nmap bug is just an incarnation of the kernel bug. I cannot actually test it here due to lack of a ppp connection (Im directly connected via ethernet for the next days).
gah Karsten any idea? Hubert JFYI.
Created attachment 49578 [details] Patch from 2.6.13.1 Please test this patch. I propose to include this in 10.0.
Increasing severity because broken pcap probably means broken tcpdump as well.
hubert, yours then
I added this patch to CVS HEAD. Please test the next KOTD.
I have asked a friend of mine which encountered this problem with freshly updated 2.6.13 too to upgrade to 2.6.13.1 and this fixed the problem for him, so I would suspect this patch to work for this problem
Unfortunatly I can still reproduce it with RC2 for a dialup connection. It's working as user, but not as root.
seems the fix did not made it on RC2, will retest with RC3 kernel soon.
RC3 kernel fixed the problem, Sorry for the noise.