Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#3752 closed defect (fixed)

Connect behavior seems broken with IOCP

Reported by: nickm Owned by: nickm
Priority: High Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: iocp tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Finally got IOCP to the point where I can turn it on, and I get a bunch of "Socket is not connected [WSAENOTCONN]". These seem to happen when connection_or_connect() calls connection_watch_events(), which calls bufferevent_enable(), which calls bev_async_consider_reading(), which fails because the connection isn't connected yet.

There's a workaround here: in the aync bufferevent case, don't call watch_events() until we're connected But perhaps also we should consider this a libevent bug: be_async_consider_{reading,writing}() and be_async_enable() should maybe return immediately if the bufferevent is in the process of connecting.

Also, Tor should eventually switch to use bufferevent_socket_connect().

Child Tickets

Change History (4)

comment:1 Changed 8 years ago by nickm

Okay. I'm trying out a patch that takes the "fix it in libevent" approach. Now instead of everything dying while connect() ing, I get:

355 connections died in state handshaking (TLS) with SSL state SSL23_ST_CR_SRVR_HELLO_A.

I'm going to hold off merging the libevent patch till I get something that bootstraps more than 85%, in case my libevent patch actually made stuff worse.

comment:2 Changed 8 years ago by nickm

Resolution: fixed
Status: newclosed

okay. pushed a set of fixes for this to Tor and Libevent. Now Tor seems to work, as a client at least, with IOCP bufferevents.

comment:3 Changed 7 years ago by nickm

Keywords: tor-client added

comment:4 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.