mbedtls_ssl_get_bytes_avail() is what you wont to call before selecting. On 16.03.2017 13:54, Noam Weissman wrote: > Hi Jan, > > No the error I am seeing is MBEDTLS_ERR_NET_RECV_FAILED > > Actually I found something interesting in my code. > > Normally when you call read (fd, buf, len) the underlying TCP will fetch the > amount you need. > > With the mbedtls_ssl_read it is a bit more complicated. As it internally > collects a record to its > own buffer before it returns to the calling part with the requested block of > data. If you read less > than the internal SSL buffer size you may have more data to read from the > internal buffer but NOT > from the socket !!. > > Because in my code, after every mbedtls_ssl_read I called select it would > have failed on the last > fragment even so that the SSL internal buffer still had some data. I added > code to check that > ssl.in_msglen == 0 before I call select again. This solved one problem but > NOT the overall reading > problem. > > If I also added large delays in code so now I am able to read 8 x 1K chunks > before I get again the > MBEDTLS_ERR_NET_RECV_FAILED > > This is a combined problem... misunderstanding how the SSL works and probably > something related > to the LwIP layer. > > If I print LwIP debug messages I have no problems reading the file. ... > delays ??? > > I also changed the call to mbedtls_ssl_set_bio to use the > mbedtls_net_recv_timeout instead of > mbedtls_net_recv function. With this change I am able to read the first SSL > record without problems > > Thanks for all the help so far :-) > > > BR, > Noam. > > -----Original Message----- > From: lwip-users [mailto:lwip-users-bounces+noam=silrd....@nongnu.org] On > Behalf Of Jan Menzel > Sent: Wednesday, March 15, 2017 10:54 PM > To: lwip-users@nongnu.org > Subject: Re: [lwip-users] PolarSSL and mbedTLS > > Hi Noam! > Did you follow the error code through mbedtls's net.c? In my code its > translated into "MBEDTLS_ERR_SSL_WANT_READ" as follows: > > int mbedtls_net_recv( void *ctx, unsigned char *buf, size_t len ) [...] > ret = (int) read( fd, buf, len ); > > if( ret < 0 ) > { > if( net_would_block( ctx ) != 0 ) > return( MBEDTLS_ERR_SSL_WANT_READ ); [...] > > with > > static int net_would_block( const mbedtls_net_context *ctx ) [...] > switch( errno ) > { > #if defined EAGAIN > case EAGAIN: > #endif > #if defined EWOULDBLOCK && EWOULDBLOCK != EAGAIN > case EWOULDBLOCK: > #endif > return( 1 ); > } > return( 0 ); > } > > Jan > > On 15.03.2017 20:30, Noam Weissman wrote: >> Hi Simon, >> >> I have triad debugging my code and added : >> #define LWIP_DEBUG LWIP_DBG_ON >> #define SOCKETS_DEBUG LWIP_DBG_ON >> >> Strange that with this switches on I am able to get a file of about 38K but >> it fails at the last part, always?. >> >> Without the debug prints it never even starts, it fails on first read. >> >> I have attached my debug printout if that helps. >> >> The text is mixed with my own debug prints, sorry: >> >> File transfer starts at line 438 with: From WssHandleReadData: >> PayloadLen = 38032, DataLen = 1020 >> >> The server sends chunks of 4K, my code reads 1K at a time from the ssl layer >> hence the 1024 chunks. >> You can see that PayloadLen reduces by the DataLen chunk ... >> >> The last part received is PayloadLen 1172 DataLen 1024 ... on line >> 1512 >> >> It should read one 1024 block and then 148 bytes and finish... This >> never happens and it fails on last read This is consistent on every test I >> did ?. >> >> If I turn off the two debug switches the file transfer never starts, >> actually fails on first read and the lwip_recvfrom returns with -1 and >> set_errno(EWOULDBLOCK); on line 773 in sockets.c (lwip ver 2.02) >> >> >> Any ideas ? >> >> >> Many thanks, >> Noam. >> >> >> >> -----Original Message----- >> From: lwip-users [mailto:lwip-users-bounces+noam=silrd....@nongnu.org] >> On Behalf Of Simon Goldschmidt >> Sent: Friday, March 10, 2017 10:36 AM >> To: lwip-users@nongnu.org >> Subject: Re: [lwip-users] PolarSSL and mbedTLS >> >> Noam Weissman wrote: >>> I get a read error inside lwip_recvfrom function. >>> [..] >>> If anyone has any ideas on what more to check or test please respond. >> >> 1: Get an idea of the error (if recvfrom returns -1, what's the >> corrent errno?) >> 2: Get a debugger and try to find out why recvfrom returns an error. Without >> that information, there's no way of knowing where the error is. >> >> Simon >> >> _______________________________________________ >> lwip-users mailing list >> lwip-users@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/lwip-users >> >> >> >> _______________________________________________ >> lwip-users mailing list >> lwip-users@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/lwip-users >> > > _______________________________________________ > lwip-users mailing list > lwip-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/lwip-users > > _______________________________________________ > lwip-users mailing list > lwip-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/lwip-users >
-- peperoni Dr. Jan Menzel Wiesenrautenstieg 42 22607 HAMBURG GERMANY Tel: +49 / 40 / 600 877 -51 Fax: +49 / 40 / 600 877 -53 http://www.peperoni-light.de mailto:i...@peperoni-light.de fingerprint: 0E46 05D8 7EF2 588E FD27 45B5 079A 400E 976D 6FA1
signature.asc
Description: OpenPGP digital signature
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
