Nmap Development mailing list archives

[RFC] path-mtu.nse, host.interface_mtu, etc.


From: Kris Katterjohn <katterjohn () gmail com>
Date: Mon, 02 Aug 2010 04:24:22 -0500

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey everyone,

Soon after fixing the fragmentation options[1], I started playing around and
ended up with the attached patch and NSE script.  The script's description
sums it up pretty well, so here it is:

'Performs simple Path MTU Discovery to the target host.

TCP or UDP packets are sent to the host with the DF (don't fragment) bit
set and with varying amounts of data.  If an ICMP Fragmentation Needed
is received, or no reply is received after retransmissions, the amount
of data is lowered and another packet is sent.  This continues until
(assuming no errors occur) a reply from the final host is received,
indicating the packet reached the host without being fragmented.

Not all MTUs are attempted so as to not expend too much time or network
resources.  Currently the relatively short list of MTUs to try contains
the plateau values from Table 7-1 in RFC 1191, "Path MTU Discovery".
Using these values significantly cuts down the MTU search space.  On top
of that, this list is rarely traversed in whole because:
    * the MTU of the outgoing interface is used as a starting point, and
    * we can jump down the list when an intermediate router sending a
      "can't fragment" message includes its next hop MTU (as described
      in RFC 1191 and required by RFC 1812)'


So now when Nmap enumerates the available interfaces, it'll also store the MTU
as retrieved via SIOCGIFMTU or libdnet.

NSE scripts can obtain the MTU value as host.interface_mtu, which corresponds
to host.interface.  This could be useful for future raw IP scripts, or if
other link layers are supported like Ethernet currently is.

The MTU is also printed in --iflist output:

DEV  (SHORT) IP/MASK         TYPE        UP MTU   MAC
lo   (lo)    127.0.0.1/8     loopback    up 33578
eth0 (eth0)  192.168.10.6/24 ethernet    up 1500  00:0C:76:7D:90:33
sl0  (sl0)   192.168.1.1/32  point2point up 296


I've all ready committed the following related changes which aid the path-mtu
script (and potentially any future NSE script utilizing raw IP) but also make
sense otherwise:

[r19378] Sendto() doesn't retry sending if errno is EMSGSIZE: sleeping for a
few seconds won't shorten the packet.

[r19379] IP packets are no longer fragmented if the DF bit is set, even if
o.fragscan is set.  If a packet is built to explicitly avoid fragmentation,
honor it.  No packets currently built in Nmap appear to set this bit.


The script and patch contain (IMO) separately useful additions which happen to
be related and somewhat intertwined, so it makes the most sense submitted
together.  The patch is pretty simple anyway.

I've tested this on Linux, NetBSD and Windows XP and all seems well.  If there
are no objections, I'll commit later this week.

Cheers,
Kris Katterjohn

[1] http://seclists.org/nmap-dev/2010/q3/207

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMVo7FAAoJEEQxgFs5kUfucBIP/R9hnJIYLo5/eT6gkBs1u0vI
rWmFiCjjP/yCltAIgMTFXT1IgWYwYScyy+25z8ISJh0omv2OZa2zN2QKu8VOV743
QlrNy75i8dk0UGPBvs1tAvXm6JLQiUWR/wfgvJSmvERqHHp1tkXtgQhRO+n2bQbM
hh7bGia1HL4B01ojVfdYG25zRFYKCBbilEPAYgWcjXJ6Ey88cEoM7ixKUNiy+f74
tbGsOGHe3cqN1d00DVKeIViHg1Cg58JEoV5dUhnM5w34DZDOoSfQVqoHb1+uXhm2
vRNz8qMxE0gpF7u2WNH9PhEt17LG/Xiqos5h3GHHpbUjT0bpfCuIdWi3Ud01XhhF
S7r8mpgQMtOPRVu70w9HObQ3xi/cejNzgDaEkeOI3USNv45OG1aTA/JeU/9YP3UG
CPYkySPgewjY0J0ONbGEYoJKUYddRP8QuqeRbnmo2zsWJDvlOW7jiALOql3ohPQ1
dvtH5neZSM7muihrAmtcIq6zRS2M2/4XdqlBf8ruAriQpI896RmBz/n2tLaEUFL7
awJEpjuo/MZ3PHkIzhip2YS7tOUwqqZfzkQxZEXefh/gapUyUmqsk1iwMkkvxyNN
bdDaWsoiJkYom4lyaXP+atcB8FL11u6+OEQVVojsMQXmLJmmlnt2F5b6Ahtowg0F
s6GqEZWvv/A9BdXxLmHz
=eTGO
-----END PGP SIGNATURE-----

Attachment: mtu.patch
Description:

Attachment: path-mtu.nse
Description:

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

Current thread: