Simon,
I am not saying that LwIP has bugs because I am not sure… It feels like that …
I asked you why when I set debug to on and all the printouts causes lots of
delays … file is transferred ?
I have set LwIP:
#define TCP_MSS 536
#define MEMP_NUM_PBUF 100
#define
This is totally off-topic to this thread... :-)
Stephen Cowell wrote:
Sorry... I was under the impression that the subject line determined the
thread.
A thread is defined by the email's headers (readable by programs), not
the subject (human readable).
I'm using Thunderbird and I don't see
Sorry... I was under the impression that the subject line determined the
thread. I'm using Thunderbird and I don't see any difference from this end.
I assume to create a new mail I address it to lwip-users@nongnu.org?
That's what I thought I did.
__
Steve
.
On 3/16/2017 1:12 PM, goldsimon
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
We're having some problems with a customer... we have over a hundred of
our lwIP 1.4.1 devices out in the field.
Our hardware is the Atmel ATSAME416E with the KSZ8081MNX PHY chip...
same config as the ATSAM4E_EK eval kit.
Project based on the THIRDPARTY_LWIP_RAW_BASIC_HTTP example.. I've
From all information given so far, I fail to see how this would be an lwip
problem.
Did you test your SSL application on a different platform and it worked or what
makes you think of an lwip problem instead of an application problem?
Don't get me wrong, lwip can have bugs. I just don't see
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
