Bug 115846

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.