mailing list archives
Re: [PATCH] TCP Idle Scan in IPv6
From: David Fifield <david () bamsoftware com>
Date: Wed, 14 Aug 2013 22:16:08 -0700
On Fri, Jul 26, 2013 at 05:19:30PM +0200, Mathias Morbitzer wrote:
I finished the new version of my patch, which enables Nmap to execute the TCP Idle Scan in IPv6.
The source code is also available on Github: https://github.com/mmorbitzer/nmap/tree/idlescan6
Thanks. I started to merge parts of this patch but ran into some
The change to get_ipid_sequence needs some more thought. When you are
dealing with 16-bit IPv4 ID values, and you start treating them as
32-bit, you will have calculation errors at the 16-bit boundary. Imagine
two consecutive IP ID values are 0xfffe and 0x0001.
(u16) 0x0001 - (u16) 0xfffe == 3
(u32) 0x0001 - (u32) 0xfffe == 4294901763
Do you have ideas as to how to account for this? Perhaps you need to
sequence calculation to be aware of whether it is handling 16-bit or
I saw you added a new IPID_SEQ_INCR_BY_2, which is probably the right
way to do it. However, not only idle scan uses the IPID_SEQ
classifications; OS detection uses them as well. Specifically, we need
to decide what to do with IPID_SEQ_INCR_BY_2 in make_aval_ipid_seq. This
is the code that controls what gets printed for the SEQ.TI, SEQ.CI, and
SEQ.II IPv4 OS detection tests: http://nmap.org/book/osdetect-methods.html#osdetect-ti.
We have two options: one is to add a new value for "increment by 2", for
instance to make TI=2 possible; and the other is to find out what hosts
having "increment by 2" behavior are currently being classified as, and
make hosts that increment by 2 map to this value, for instance TI=I or
What did get_ipid_sequence return for hosts that increment by 2, before
your patch causing them to be IPID_SEQ_INCR_BY_2?
Sent through the dev mailing list
Archived at http://seclists.org/nmap-dev/