Nmap Development mailing list archives
Re: [RFC] Nsock connect error handling
From: Daniel Miller <bonsaiviking () gmail com>
Date: Mon, 20 Mar 2017 12:13:05 -0500
Thanks for confirming, David. I committed this change in r36653. Dan On Thu, Mar 16, 2017 at 10:44 PM, David Fifield <david () bamsoftware com> wrote:
On Thu, Mar 16, 2017 at 10:37:51PM -0500, Daniel Miller wrote:I was just looking at a bug report [1] that showed that an ICMP Type 12 (Parameter Problem) packet could cause Nsock to throw a fatal error.Timed justright, this could crash Nmap during version scan. The fix is simple: addEPROTOto the long list of known error codes in handle_connect_result [2]. Butis thatthe best option? As far as I can tell, there is no reason for Nsock to be checking forspecificerror codes. The action is always the same: return a Nsock error and settheerror code appropriately. The only non-error condition is explicitlyhandled:connect() returns 0, and Nsock returns success. Why can't we make thedefaultcase handle any error code possible?I think you're right on both counts. You can fix the bug by adding EPROTO to the list of known errors. And, the default error case could be made to handle any error generically. _______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
_______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- [RFC] Nsock connect error handling Daniel Miller (Mar 16)
- Re: [RFC] Nsock connect error handling David Fifield (Mar 16)
- Re: [RFC] Nsock connect error handling Daniel Miller (Mar 20)
- Re: [RFC] Nsock connect error handling David Fifield (Mar 16)