Re: Latest Nmap = Segmentation fault

[Diman Todorov <diman.todorov () univie ac at>]

On Dec 4, 2007, at 10:26 AM, Lionel Cons wrote:
> Well, the problem is still there with -sV

okay, I seem to have misjudged your problem. I committed a fix to the  
svn repository. To avoid the segfault with the current nmap release,  
you need to set the port.version_service_tunnel value (either "none"  
or "ssl"). The fix I committed uses "none" as the default value if the  
version_service was not set.

But just on a side note, what are you trying to accomplish? I have a  
hunch that you may be doing things more awkwardly than necessary. If a  
UDP port is reported as closed it means that nmap is pretty sure that  
the port is closed. If the service you are probing does not respond at  
all, nmap will mark the port as open|filtered. From the nmap docs:

<snip>
UDP scan works by sending an empty (no data) UDP header to every  
targeted port. If an ICMP port unreachable error (type 3, code 3) is  
returned, the port is closed. Other ICMP unreachable errors (type 3,  
codes 1, 2, 9, 10, or 13) mark the port as filtered. Occasionally, a  
service will respond with a UDP packet, proving that it is open. If no  
response is received after retransmissions, the port is classified as  
open|filtered. This means that the port could be open, or perhaps  
packet filters are blocking the communication. Versions scan (-sV) can  
be used to help differentiate the truly open ports from the filtered  
ones.
</snip>

You can have a port rule which matches against an open|filtered port.  
You can also adjust how long the script should wait for a response  
from the UDP port before it gives up.

cheers,
Diman

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org