[ENBD] problem of ssl

[Peter T. Breuer]

"A month of sundays ago Peter T. Breuer wrote:"
> I haven't tested ssl at all during development of the 2.4.* line.  It
> would not surprise me if ssl had broken somehow along the way.  Drop
> back to a version where it works for sure (the 2.2.* series springs to
> mind!).  Then try and locate a version change where it stops working.

OK .. with andres I have mended the compile breakage under USING_SSL=1
in nbd 2.4.18 (I'm surprised that 2.4.15 compiled).  Now
I am looking at what happens with the connect. It does look like
the explanation below is what happens  ...

> One of the things that did happen in 2.4.* was that the initial
> communications became more "unix like", with a listening socket 
> splitting off communication channels on a fixed port as necessary.
> That may be implicated if there is some ssl breakage.

There's a good possibility of fixing it in the next few days.

> (cc'ed to andres who did the ssl work and knows all about it).

The certificates get built correctly, but then ...

   sh -c  "sudo nice -19 /tmp/nbd-client localhost 3033 localhost  -b 1024
   -t 120 -CAfile /tmp/cacert.pem -cert /tmp//localhost_client.pem -verify
   1   -p 5 -d 1 /dev/nda ; pstree -p | grep nbd-client; sleep 90"
   nbd-client: no process killed
   nbd-client: no process killed
   rmmod: module nbd not loaded
     certificado="/tmp//localhost_client.pem"
    clave="(null)"
    nbd-client: client (-1) starts introduction sequence on port 3033
    nbd-server: server (-1) opened port #3033 on socket 1
    |-nbd-client(25221)
       nbd-client: Failed/Helo: Success
       nbd-client: client (-1) fails in expect sequence

which as far as I can see, means that the server opened an ordinary
unix socket and the client tried to talk to it with an ssl one. The
failure is in the "session start" interchange between the chief daemons,
which is good, because that's a big  mistake, not a small one.

It will require some code-walkthrough. Time to add comments.


Peter