Nmap Development mailing list archives
Re: idea for scanning options
From: David Fifield <david () bamsoftware com>
Date: Mon, 23 Feb 2015 15:47:21 -0800
On Mon, Feb 23, 2015 at 04:52:48PM -0600, Daniel Miller wrote:
On Fri, Jan 9, 2015 at 11:05 PM, Mike . <[1]dmciscobgp () hotmail com> wrote: so follow along here because maybe this wont make sense, not sure. would someone ever think about making a change in our scanning (tcp/udp) to ALWAYS have the source port match destination? i read that some protocols will only talk this way. 2 i know are IPSEC and RIP (500/520). i do believe there are others but i do not recall them right now. so as you would be scanning, by default, it would just use the same source as dest on auto. is this feasible and do we even care? maybe we could do certain ports this way? or do you want the user to constantly specify the src port option? This could be feasible, but would require a good deal of work to implement. I thought at first that it would not be possible, since we use the source port to encode information about how many retries had been sent since the one that provoked the response. This helps with timing, since it lets us know when there is a very high-latency link where replies to earlier probes arrive after we have already sent retransmissions. This is already a consequence of using the -g option to set the source port, though.
It should be possible because of -g, but I agree it doesn't seem worth the effort. It would be weird to probe port 80 from source port 80 always, for example. David _______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- idea for scanning options Mike . (Jan 09)
- Re: idea for scanning options Daniel Miller (Feb 23)
- Re: idea for scanning options David Fifield (Feb 23)
- Re: idea for scanning options nnposter (Feb 23)
- Re: idea for scanning options David Fifield (Feb 23)
- Re: idea for scanning options Daniel Miller (Feb 23)