Re: [Libevent-users] using libEvent 2.x with Visual C++

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Sat, Jun 9, 2012 at 12:18 AM, Patrick Pelletier
<ppelletier@xxxxxxxxxx> wrote:
> On 06/08/2012 01:55 PM, Nick Mathewson wrote:
>
>> Looks like I never added evutil_time.c to Makefile.nmake when I added
>> it to Makefile.am.  Should be fixed in 0ba0683bcfc8652a8c50.
>
>
> Thanks; that works for me!
>
> I've also taken it a bit further, and added support for OpenSSL to
> Makefile.nmake.  Unfortunately, I don't know nmake very well (I haven't yet
> looked up how to do conditionals, for example), so my Makefile.nmake is very
> hacked up right now and not suitable for general use.  But if anyone wants
> to peek at it, in its current ugly state, it's on my "windows-ssl" branch on
> github at git://github.com/ppelleti/libevent.git
>
> So, after building libevent with ssl, I ran regress.exe, and got this (with
> boring lines omitted for brevity)
>
> main/methods: [forking] OK
> main/version: OK
> ...
> util/monotonic: OK
> util/monotonic_precise: OK
> util/monotonic_fallback:
>  FAIL regress_util.c:1273: assert(evutil_timercmp(&tv[i], &tv[i+1], <))
>  [monotonic_fallback FAILED]
> bufferevent/bufferevent: [forking] OK
> ...
> iocp/listener/randport: [forking] OK
> iocp/listener/error: [forking] OK
> ssl/bufferevent_socketpair: [forking] OK
> ssl/bufferevent_filter: [forking] OK
> ssl/bufferevent_renegotiate_socketpair: [forking]
>  FAIL regress_ssl.c:335: assert(test_is_done == 1)
>  [bufferevent_renegotiate_socketpair FAILED]
> ssl/bufferevent_renegotiate_filter: [forking]
>  FAIL regress_ssl.c:335: assert(test_is_done == 1)
>  [bufferevent_renegotiate_filter FAILED]
> ssl/bufferevent_socketpair_startopen: [forking] OK
> ssl/bufferevent_filter_startopen: [forking] OK
> ssl/bufferevent_connect: [forking] OK
> 3/196 TESTS FAILED. (15 skipped)
>
> I poked around in regress_ssl.c a little bit, but haven't yet figured out
> exactly why the test_is_done assertion is failing.  I might look at it some
> more later.  (I'm using OpenSSL 1.0.1c.)

This is actually a known bug with openssl 1.0.1...1.0.1c: it can't do
renegotiation with itself when it has negotiatied TLS 1.1 or TLS 1.2.
They have a patch for it here:
   http://cvs.openssl.org/chngview?cn=22567
but it doesn't seem to be in a release yet.

Is the monotonic_fallback failure consistent, or does it only happen
some of the time?

-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.