failed pings in nmapwin

["yeti" <boxed () blueyonder co uk>]

Often, when scanning, ive had to -P0 when i can easally ping the target (using ping :P). When i tryed to trace the 
problem (i used --packet_trace and windump to verify), i found that i was not sending any echo packets from my real ip 
(i was using decoys), but instead was sending echo's from 0.0.0.0 

I tried to correct this using -S, but i still had the same problem. Here is the offending output.

F:\Fport>nmap -sS tt.tt.tt.tt -D dd.dd.dd.dd,d2.d2.d2.d2,ME -p 21 -PI -vv
-d --packet_trace --data_length 0 -ttl 250 -S ss.ss.ss.ss
WARNING:  If -S is being used to fake your source address, you may also have to
use -e <iface> and -P0 .  If you are using it to specify your real source addres
s, you can ignore this warning.

Starting nmap 3.27 ( www.insecure.org/nmap ) at 2003-05-30 20:04 GMT Daylight Ti
me
SENT (0.0800s) ICMP dd.dd.dd.dd > tt.tt.tt.tt Echo request (type=8/code=0)
ttl=250 id=39504 iplen=28
SENT (0.0800s) ICMP d2.d2.d2.d2 > tt.tt.tt.tt Echo request (type=8/code=0) t
tl=250 id=12590 iplen=28
SENT (0.0900s) ICMP 0.0.0.0 > tt.tt.tt.tt Echo request (type=8/code=0) ttl=25 #this should be from ss.ss.ss.ss right?
0 id=53537 iplen=28
SENT (6.0980s) ICMP dd.dd.dd.dd > tt.tt.tt.tt Echo request (type=8/code=0)
ttl=250 id=29014 iplen=28
SENT (6.0980s) ICMP d2.d2.d2.d2 > tt.tt.tt.tt Echo request (type=8/code=0) t
tl=250 id=812 iplen=28
SENT (6.0980s) ICMP 0.0.0.0 > tt.tt.tt.tt Echo request (type=8/code=0) ttl=25 #this should be from ss.ss.ss.ss right?
0 id=11051 iplen=28
Finished block: srtt: -1 rttvar: -1 timeout: 6000000 block_tries: 2 up_this_bloc
k: 0 down_this_block: 0 group_sz: 1
massping done:  num_hosts: 1  num_responses: 0
Host 63.219.143.152 appears to be down, skipping it.
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0

Nmap run completed -- 1 IP address (0 hosts up) scanned in 12.107 seconds

The strange thing is that it works (doesnt use 0.0.0.0 with -PT, but although the sever responds, i still get host not 
up.). This might be a winpcap problem, as the --packet_trace doesnt seem to recive the -PT response.

I run Win2k with a 512k broadband with nmap 3.27 and winpcap 2.3