mailing list archives
Re: Latest Nmap = Segmentation fault
From: Diman Todorov <diman.todorov () univie ac at>
Date: Tue, 4 Dec 2007 11:39:12 +0100
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:
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
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.
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org