Hi,
I am new to lwip.
basic:
1) I have two ethernt port.(external word interface)
2) Only one ip address is assigned to both the port.
3) RMII interface is used.(3rd port which is going to controller).
Set up:
1) Both ports are connected to external ethernet switch.
2) PC is connected to ethernet
I figured out how to get the wireshark trace,
but how to get the wireshark GUI to output the summary below in text
baffles me, hope the pic is OK:
Everything is going swimmingly until 4316.
I don't understand the meaning of "previous segment not captured" here -
something got dropped.
And then
On 26.02.2019 22:07, Slava Zilberfayn wrote:
Hello all,
I've done some more testing with tcpecho example. When I set
chunk size to be less than the size of the tcpecho
packets, I get exactly the same failure during the second
call to netconn_write. When the packet size small than ch
Hello all,
I've done some more testing with tcpecho example. When I set
chunk size to be less than the size of the tcpecho
packets, I get exactly the same failure during the second
call to netconn_write. When the packet size small than chunk
size it crashes fairly quickly. For example
On 26.02.2019 17:15, Giuseppe Modugno wrote:
Il 26/02/2019 09:58, Simon Goldschmidt ha scritto:
Giuseppe Modugno wrote:
[snip]
No. TCP_WND is not something you have allocated. It's the amount of data
the remote host can send before we reopen the window.
In the altcp TLS case, the data is re
Il 26/02/2019 09:58, Simon Goldschmidt ha scritto:
Giuseppe Modugno wrote:
An: lwip-users@nongnu.org
Betreff: Re: [lwip-users] altcp_tls_mbedtls
Il 25/02/2019 20:19, goldsi...@gmx.de ha scritto:
Am 22.02.2019 um 10:24 schrieb Giuseppe Modugno:
Il 22/02/2019 09:43, Simon Goldschmidt ha scritto
Hello Lwip-users,
I have a networked device that was running lwIP 1.4.1 in the
past, but now I'm upgrading it to 2.1.0. The reason for the
upgrade is that we have a bit of instability. I have
previously identified two bugs in 1.4.1 that we were hitting,
and applied fixes. But since we
> While we're at it, I have one more question. After the fix described
> above the application is running much much better and the connection
> looks a lot more stable/reliable. But I do still see some rare
> occurrences of TCP retransmissions and duplicated ACKs in Wireshark
> (like maybe once/twi
Giuseppe Modugno wrote:
> An: lwip-users@nongnu.org
> Betreff: Re: [lwip-users] altcp_tls_mbedtls
>
> Il 25/02/2019 20:19, goldsi...@gmx.de ha scritto:
> > Am 22.02.2019 um 10:24 schrieb Giuseppe Modugno:
> >> Il 22/02/2019 09:43, Simon Goldschmidt ha scritto:
> >
> > [snip]
> >
> Is this warn
Il 25/02/2019 20:19, goldsi...@gmx.de ha scritto:
Am 22.02.2019 um 10:24 schrieb Giuseppe Modugno:
Il 22/02/2019 09:43, Simon Goldschmidt ha scritto:
[snip]
Is this warning correct? I think TCP_WND should be compared with
MBEDTLS_SSL_IN_CONTENT_LEN or MBEDTLS_SSL_OUT_CONTENT_LEN or the
maxi
Giuseppe Modugno wrote:
[..]
> >> What are the situations when it should be better to not call
> >> tcp_recved() in recv() callback()? Here the application has the
> >> received data, can process and free the pbufs or can avoid freeing
> >> the pbufs to wait for additional data. In both cases I
Il 25/02/2019 20:23, goldsi...@gmx.de ha scritto:
Am 23.02.2019 um 10:20 schrieb Giuseppe Modugno:
I know, this is a hot topic and many times this was explaied in the
list and in doc/rawapi.txt, however now I'm in trouble understanding
this.
tcp_recved() is related to the TCP window size of t
> I don't know @BernardXiong or @hichard, but the NAT code is clearly marked
> as originating 2009 from Christian Walter. He was the one uploading this
> code to our bugtracker in 2009, without the right to do so, obviously.
>
> I ended up deleting these files from the bugtracker, but it seems they
Ajay Bhargav wrote:
> An: "Mailing list for lwIP users"
> Betreff: Re: [lwip-users] Using LWIP with PPP and NAT
>
> > That ones seems pretty inactive? Also, they seem to have a mixed license
> > where the NAT part seems to be GPL, while lwIP has a BSD license.
> >
> > In addition to that, the ip4_
14 matches
Mail list logo