Re: [Nmap, Ncat] Odd Nsock bug related to ENETUNREACH

[Henri Doreau <henri.doreau () gmail com>]

2014-06-05 21:43 GMT+02:00 Henri Doreau <henri.doreau () gmail com>:
> 2014-06-05 13:38 GMT+02:00 Jacek Wielemborek <d33tah () gmail com>:
> > List,
> >
> > While working on my prototype, I noticed that when you try to
> > make a connection that results in ENETUNREACH (tested by issuing
> > ncat 127.0.0.0 -w 1), Nsock blocks forever even if a timeout was
> > specified. This is probably because it performs a non-blocking
> > connect() and ignores any error codes other than EINPROGRESS or
> > EAGAIN, yet it schedules an event. Then, the main loop calls
> > engine's file descriptor watching function (epoll, select etc) on
> > an empty FD set, effectively waiting forever.
> >
> > This affects NSE scripts as well. Create test.nse file with the
> > folowing code and run nmap --script test.nse -d 127.0.0.0 -sn:
> >
> > local stdnse = require "stdnse"
> > local nmap = require "nmap"
> >
> > hostrule = function()
> >   return true
> > end
> >
> > action = function(host)
> >         stdnse.print_debug("test.nse started!")
> >         local sock = nmap.new_socket()
> >         local constatus, conerr = sock:connect("127.0.0.0", 80)
> > end
> >
> > --END OF FILE
> >
> > I believe that Nsock should run the connect handler immediately
> > when it detects the error, behaving in a way similar to other
> > error messages.
> >
> > The box I tested it on is Fedora 20, kernel
> > 3.14.2-200.fc20.x86_64. I can provide any further details if
> > needed.
> >
> > Yours,
> > Jacek Wielemborek
>
> Interesting... I need to investigate this. I have added a new nsock
> regression test. What I could observe is that the error is delivered,
> but it breaks afterwards due to bad refcounts or something like this
> (according to the engine you use). There's definitely something wrong
> there.
>
> I'll have a closer look as soon as time permits.
>
> Regards
>
> --
> Henri

Should be fixed in r32993. The problem was that once the operation
(connect) has failed, the IOD is never marked as "active" anymore by
the I/O engines (which is totally normal), so the errors were, at
best, reported at shutdown (nsi_delete, nsp_delete...).

Early completed events are now handled even before nsock_loop() is
called. I think it's ok.

Regards

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