lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] PolarSSL and mbedTLS


From: Noam Weissman
Subject: Re: [lwip-users] PolarSSL and mbedTLS
Date: Tue, 14 Mar 2017 14:42:20 +0000

Hi Jan,

I have added parameter to the conf structure by using the function 
mbedtls_ssl_conf_max_frag_len

I have tested my client against a test server based on mbedTLS library and it 
worked !

When I triad my client side against the actual server it did not work. So it 
may not support
" Maximum Fragment Length Negotiation" option as you have mentioned.

In any case I need to integrate with the server.... continue the work.

Thanks,
Noam.



-----Original Message-----
From: lwip-users [mailto:address@hidden On Behalf Of Jan Menzel
Sent: Tuesday, March 14, 2017 4:36 PM
To: address@hidden
Subject: Re: [lwip-users] PolarSSL and mbedTLS

Hi Noam!
        IIRC this options is not widely implemented. Especially openssl seems 
to lack it. If you configure a short FRAGMENT_LENGTH and the other side does 
not respect the option, transfer of large data blocks (>~
FRAGMENT_LENGTH) will not be possible.

        Jan

On 12.03.2017 10:05, Noam Weissman wrote:
> Hi Jan, Simon...
> 
>  
> 
> I have found a solution that seems to work J...
> 
>  
> 
> A college of mine working on the server side pointed me to RFC 6066 
> were there is an option to request
> 
> the server to limit the sent fragment size:
> 
>     https://tools.ietf.org/html/rfc6066#page-8
> 
>  
> 
> The above is part of the RFC without the need to change anything in 
> LwIP or mbedTLS code. It's a simple
> 
> configuration issue.
> 
>  
> 
> I have added to my code the following:
> 
> 1.       I defined MBEDTLS_SSL_MAX_FRAGMENT_LENGTH in mbedtls_config.h
> 
> 2.       I added a call to mbedtls_ssl_conf_max_frag_len(&conf,
> MBEDTLS_SSL_MAX_FRAG_LEN_1024);
> 
>  
> 
> The above adds an extra parameter in the SSL/TLS handshake... actually 
> adds it in the HELLO handshake.
> 
>  
> 
> I need to make a few more tests but it seems to work and have no 
> problems sending even a 600K binary file.
> 
>  
> 
> I still did not catch why lwip_recvfrom function failed but the above 
> seems to be working.
> 
>  
> 
> Thanks for everyone that puts their inputs J
> 
>  
> 
> If I will have an update I will update the group.
> 
>  
> 
> BR,
> 
> Noam.
> 
>  
> 
> *From:*lwip-users 
> [mailto:address@hidden
> *On Behalf Of *Noam Weissman
> *Sent:* Sunday, March 12, 2017 12:39 AM
> *To:* Mailing list for lwIP users
> *Subject:* Re: [lwip-users] PolarSSL and mbedTLS
> 
>  
> 
> Hi Simon,
> 
>  
> 
> with SSL there is a read for 5 bytes record header and then reading 
> the data itself as a whole
> 
> or in parts (inside lwip_recvfrom).
> 
>  
> 
> My module is a single task that has a state machine. When the state is 
> in OPEN state it blocks
> 
> for 1 second on select, if select is returning with a timeout the task 
> is doing some house keeping
> 
> and returns to the OPEN state for another select etc...
> 
>  
> 
> If select is returning with 1, meaning there is data, the code issues 
> mbedtls_ssl_read etc...
> 
> The SSL code reads the 5 bytes header but fails after that. The fail 
> happens if the sending
> 
> record is more then a few K bytes. The strange thing is that it fails 
> on the first read ?
> 
>  
> 
> If it would have failed after a few blocks that were read then we 
> could assume that there
> 
> is another problem but it fails on the first read just after the 5 
> bytes header were read ?
> 
>  
> 
> My hunch is that its something stupid :-)
> 
>  
> 
> BR,
> 
> Noam.
> 
> ----------------------------------------------------------------------
> --
> 
> *From:*lwip-users <address@hidden
> <mailto:address@hidden>> on behalf of 
> address@hidden <mailto:address@hidden> <address@hidden 
> <mailto:address@hidden>>
> *Sent:* Saturday, March 11, 2017 11:29 PM
> *To:* Mailing list for lwIP users
> *Subject:* Re: [lwip-users] PolarSSL and mbedTLS
> 
>  
> 
> Noam,
> 
> that sounds a bit too complicatied...
> 
> My first thought is: you call select and it returns that there is data 
> to read, but that does not mean there is enough data to read for TLS, 
> so EWOULDBLOCK is not an error at all in this case.
> 
> Simon
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden <mailto:address@hidden> 
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> lwip-users -- Mailing list for lwIP users - lists.nongnu.org 
> <https://lists.nongnu.org/mailman/listinfo/lwip-users>
> 
> lists.nongnu.org
> 
> Welcome to the lwip-users mailing list. Use it to ask questions, share 
> your experience and discuss new ideas. To see the collection of prior 
> postings to the list ...
> 
>  
> 
> 
> 
> _______________________________________________
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]