OpenSSL: Renegotiation initiated from client - ssl

Question

I set up client-server connections using mem-BIOs. I was able to send data without socket IO. This was my reference - http://roxlu.com/2014/042/using-openssl-with-memory-bios.
Question 1:
For decryption, it used, BIO_write() and then SSL_read(). If via socket IO, the record is over 2 packets, what do I need to take care? If SSL_read() returns SSL_ERROR_WANT_READ, does it mean that data is buffered in in_bio and I need to call BIO_write() and SSL_read() again for 2nd packet and this time, SSL_read() will return SSL_ERROR_NONE?
Question 2:
I am trying to understand the SSL renegotiation handshake. Does it go through a 4-way handshake again? Or should it just do a 2-way handshake and a client-hello may not be necessary again? Please share any info on the renegotiation handshake exchange.
Now, I have added this code to the above reference example:
main() {
<snip - Initial handshake>
</snip>
SSL_renegotiate(client.ssl);
SSL_do_handshake(client.ssl);
krx_ssl_handle_traffic(&client, &server);
krx_ssl_handle_traffic(&server, &client);
krx_ssl_handle_traffic(&client, &server);
krx_ssl_handle_traffic(&server, &client);
}
I see these through callbacks:
+ client: HANDSHAKE START - before connect initialization - CINIT
+ client: LOOP - SSL renegotiate ciphers - UNKWN
+ client: LOOP - SSLv3 write client hello A - 3WCH_A
+ server: HANDSHAKE START - before accept initialization - AINIT
+ server: LOOP - before accept initialization - AINIT
+ server: LOOP - SSLv3 read client hello A - 3RCH_A
+ server: LOOP - SSLv3 write server hello A - 3WSH_A
+ server: LOOP - SSLv3 write certificate A - 3WSC_A
+ server: LOOP - SSLv3 write certificate reques - 3WCR_A
+ server: LOOP - SSLv3 write server done A - 3WSD_A
+ server: LOOP - SSLv3 flush data - 3FLUSH
+ client: LOOP - SSLv3 read server hello A - 3RSH_A
+ client: LOOP - SSLv3 read server certificate - 3RSC_A
+ client: LOOP - SSLv3 read server certificate - 3RCR_A
+ client: LOOP - SSLv3 read server done A - 3RSD_A
+ client: LOOP - SSLv3 write client certificate - 3WCC_A
+ client: LOOP - SSLv3 write client key exchang - 3WCKEA
+ client: LOOP - SSLv3 write certificate verify - 3WCV_A
+ client: LOOP - SSLv3 write change cipher spec - 3WCCSA
+ client: LOOP - SSLv3 write finished A - 3WFINA
+ client: LOOP - SSLv3 flush data - 3FLUSH
+ server: LOOP - SSLv3 read client certificate - 3RCC_A
+ server: LOOP - SSLv3 read client key exchange - 3RCKEA
+ server: LOOP - SSLv3 read certificate verify - 3RCV_A
+ server: LOOP - SSLv3 read finished A - 3RFINA
+ server: LOOP - SSLv3 write session ticket A - UNKWN
+ server: LOOP - SSLv3 write change cipher spec - 3WCCSA
+ server: LOOP - SSLv3 write finished A - 3WFINA
+ server: LOOP - SSLv3 flush data - 3FLUSH
+ server: HANDSHAKE DONE - SSL negotiation finished succe - SSLOK
+ client: LOOP - SSLv3 read server session tick - UNKWN
+ client: LOOP - SSLv3 read finished A - 3RFINA
+ client: HANDSHAKE DONE - SSL negotiation finished succe - SSLOK
Thanks.

Answer 1

Q1. Packets and _WANT_READ
You aren't at all clear on what your packets are. When using SSL/TLS over TCP (the normal case) an SSL/TLS record can be up to a little over 16k octets, while on most network paths TCP generally uses a packet (aka segment) size of about 1400. It may take more than 10 of these packets to complete one record. And when it does, that record might not be an ApplicationData record; if it isn't, SSL_read still won't have data to return and it will instead act according to the protocol, which may involve further reads AND/OR WRITES before it returns data. You should not try to guess what nonblocking SSL_read (or SSL_write either) are going to do; you should always look at their return values, and the 'extended' values from SSL_get_error (which is the routine that actually returns SSL_WANT_{READ,WRITE} etc, NOT SSL_read and SSL_write). This is explained on the man pages, which I encourage you to read if you haven't already. If you're on non-WSL Windows where man pages aren't used, see the website.
Q2. Renegotiation
(Note: answer for TLS through 1.2 only; 1.3 definitely changes the normal handshake very substantially, and I believe also renegotiation, but I haven't gone through it in detail yet.) Except that it starts while a session (crypto context) is already in use, and may be initiated by the server with RequestHello, and (importantly) can use the Renegotiation Indication extension (RFC5746) to prevent the "Apache-splice" attack (CVE-2009-3555), re-negotiation is (almost) the same as initial negotiation. If a full handshake it takes four flights (two round-trips); if an abbreviated handshake (resuming a pre-existing session) it takes three flights but the last can be combined with client data which often reduces it to one round-trip. See my answer at https://security.stackexchange.com/questions/91248/questions-about-triple-handshakes-considered-harmful-breaking-and-fixing-authen (whose relevance is admittedly unobvious) for a riff on this. See RFC 5246 et pred for the handshake