Re: [lwip-users] PolarSSL and mbedTLS

[Noam Weissman]

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:address@hidden On Behalf Of Jan Menzel
Sent: Wednesday, March 15, 2017 10:54 PM
To: address@hidden
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:address@hidden 
> On Behalf Of Simon Goldschmidt
> Sent: Friday, March 10, 2017 10:36 AM
> To: address@hidden
> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users