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: Sun, 12 Mar 2017 09:05:08 +0000

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:lwip-users-bounces+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 <lwip-users-bounces+address@hidden> on behalf of address@hidden <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
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 ...

 


reply via email to

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