[lwip-users] Two ethernet port with one mac address
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 switch. when only one port of DUT (device under test) is connected to ethernet switch; pinging from pc on individual port is working fine. Problem: when both the ports of DUT (device under test) is connected to ethernet switch; ping is not working. -- Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Throughput benchmark question - nasty pauses
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 it takes a second to get going again. Any pointers appreciated! Thanks, Best Regards, Dave On 2/20/2019 1:45 AM, Johan Borkhuis wrote: Dave, First thing would be to sniff the network using Wireshark, and see what happens there when the traffic pauses. This would usually give a good indication on what did happen. Regards, Johan On 2019-02-20 00:15, Dave Nadler wrote: Hi - Newbie here trying to do some basic throughput tests. LwIP 2.1.2 on FreeRTOS 9, ST32F429, IPv4, TCP. I want to see how much I can consistently push through the stack. Made a simple test server (sockets API) which repeatedly outputs 101-character lines. I access the server via PuTTY raw mode on Winbloze over a local network. I can usually send 3 lines per msec for a second (3000 lines in 1 second), but... Sometimes, I get ~ 1-second pauses (as seen in Putty or TeraTerm). How should I go about understanding where the pauses come from? Thanks in advance for any hints, Best Regards, Dave -- Dave Nadler, USA East Coast voice (978) 263-0097, d...@nadler.com, Skype Dave.Nadler1 ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users -- Dave Nadler, USA East Coast voice (978) 263-0097, d...@nadler.com, Skype Dave.Nadler1 ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwIP trouble
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 chunk size it crashes fairly quickly. For example I set chunk size to 400 in the tcpecho example and send 400 bytes packets to it. Works fine. If I start sending 401 bytes, it crashes fairly quickly. There must me something wrong with my settings. Any help would be appreciated. If you could get this reproduced with minimal changes on the win32 or linux port, it would be *much* easier to see what's going on. Regards, Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwIP trouble
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 I set chunk size
to 400 in the tcpecho example and send 400 bytes packets to
it. Works fine.
If I start sending 401 bytes, it crashes fairly quickly.
There must me something wrong with my settings. Any
help would be appreciated.
Thanks, Slava
Monday, February 25, 2019, 9:30:28 PM, you wrote:
SZ> Hello Lwip-users,
SZ> I have a networked device that was running lwIP 1.4.1 in the
SZ> past, but now I'm upgrading it to 2.1.0. The reason for the
SZ> upgrade is that we have a bit of instability. I have
SZ> previously identified two bugs in 1.4.1 that we were hitting,
SZ> and applied fixes. But since we still have occasional faults,
SZ> I decided to upgrade. The application is an http_server that
SZ> uses netconn API.
SZ> Now, I have also upgraded the FreeRTOS, which went relatively
SZ> trouble free.
SZ> WithlwIPIfirsthitthenew #ifdef in
SZ> netconn_write_vectors_partly:
SZ> #if LWIP_SO_SNDTIMEO
SZ> if (conn->send_timeout != 0) {
SZ> dontblock = 1;
SZ> }
SZ> #endif /* LWIP_SO_SNDTIMEO */
SZ> if (dontblock && !bytes_written) {
SZ> /* This implies netconn_write() cannot be used for non-blocking send,
since
SZ>it has no way to return the number of bytes written. */
SZ> return ERR_VAL;
SZ> }
SZ> I was using netconn_write() macro, and so it was exiting
SZ> here with ERR_VAL.
SZ> I switched to netconn_write_partly() and it made things work,
SZ> sort of. I'm testing the access of a single file. It works
SZ> about 90% of the time, but the other 10% it explodes in a
SZ> strange way.
SZ> Here is the log file.
SZ> Netcnn a009879c
SZ> http_server_netconn_thread: Sending Message
SZ> Netcnn 2 a009879c
SZ> http_file_server: Processing Message
SZ> netconn_recv...
SZ> resource requested = '/s.xml'
SZ> tcp_write(), LR = 28a77
SZ> tcp_write(pcb=a0098eac, data=10003160, len=68,
SZ> apiflags=1)
SZ> tcp_write: queueing 1b1c:1b60
SZ> tcp_output_segment: 1b1c:1b60
SZ> XML Generated 2000 bytes
SZ> calling netconn_write_partly 36
SZ> tcp_write(), LR = 28a77
SZ> tcp_write(pcb=a0098eac, data=1000c2c0, len=1460,
SZ> apiflags=1)
SZ> tcp_write: queueing 1b60:2114
SZ> tcp_output_segment: 1b60:2114
SZ> calling netconn_write_partly 37
SZ> tcp_write(), LR = 28a7tcp_write(), LR = 28a77
SZ> tcp_write(pcb=a0098eac, data=1000c874, len=540,
SZ> apiflags=1)
SZ> tcp_write: queueing 2114:2330
SZ> tcp_output_segment: 2114:2330
SZ> 7
SZ> tcp_write(pcb=a0098eac, data=1000c874, len=540,
SZ> apiflags=1)
SZ> tcp_write: queueing 2330:254c
SZ> HARD FAULT
SZ> _CFSR 8200
SZ> _BFAR 18
SZ> LR 2022d
SZ>
SZ> Ihave added the * manually to demark the
SZ> intervening call. What I see is that in
SZ> the middle of the tcp_write execution another call of
SZ> tcp_write comes in with exactly the same parameters.
SZ> Presumably to send the same piece of data. I've added
SZ> printing LR register at the entry into tcp_write to see there
SZ> it is called from. Both calls come from the same location
SZ> (api_msg.c:1712). Now I'm kind out of ideas. Any pointers
SZ> where to look at would be appreciated.
SZ> attached are my config files.
SZ> Thank you, Slava
--
Slava Zilberfayn mailto:szil...@home-electro.com
Phone: 416 7289367
Home Electronics, www.home-electro.com
100 Drumlin Circle,
Suite 205
Concord, ON, L4K 3E6
CANADA
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] altcp_tls_mbedtls
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 received and ACKed, then the TLS adaption layer passes it into mbedtls and frees the buffer. However, the window update is sent by the application code that is TLS-agnostic. So the window update is only sent after the block has been decrypted. Could you point me to the code that reopen the window after the block has been decrypted? I couldn't find it, my shame. There's not "the code" that does this. The raw tcp callback application does this by calling altcp_recved(), which is directly mapped through to the lower protocol (TCP in this case). The mbedtls layer only calls tcp_recved() for the overhead bytes that don't get handled by the application, so that it is ensured the window always reopens correctly. Isn't possible to reopen the window (call tcp_recved) even when a partial TLS block is received? I couldn't understand why lwip needs to reopen the window only when an entire block is received (and decrypted by mbedTLS). Suppose 1kB of a 16kB encrypted block is received, altcp_tls_mbedtls pass the data to the application mbedTLS that copy them in its buffer, then frees the received pbufs. Now we can reopen the window. What's wrong with this approach that can keep TCP_WND small? That would also be possible. But then you would lose the ability for the application to throttle the remote host's sending speed (in case the application handles data slower than it possibly arrives - again, think of an upload programmed to flash). You'd then just call tcp_recved for everyhing you successfully pass into mbedtls and ensure the altcp_recved() calls from the application don't get passed through to TCP. And since such a block may be up to 16 kByte, the tcp window has to be at least that big, too, or you can get a deadlock. Suppose I have a TCP_WND of only 2kB and incoming TLS buffer of 16kB. The TLS transmitter could send maximum 2kB of data that are buffered in the lwip receiving window. lwip calls altcp_recv(), so altcp_mbedtls_lower_recv() with received data (2kB maybe segmented in small pbufs and pbuf chains). I can't follow the code, but I expect those data are immediately passed to mbedTLS library that should copy those data to its 16kB incoming buffer, freeing receiving window. I think the lwip TCP receiving window could be smaller than mbedTLS incoming data buffer. To make the receiving window smaller, you'd have to change the code. However, you would gain nothing: TCP_WND is *not* a buffer. The actual buffer is in mbedtls and you can't shrink that. TCP_WND just describes this behaviour. TCP_WND isn't a buffer, however I need to reserve a sufficiently sized memory pools (I'm using memory pools for pbufs with MEMP_MEM_MALLOC=0). And memory pools are statically allocated memory, so I end up with 16kB allocated buffer for mbedTLS and 16kB memory pools for storing at least TCP_WND bytes. In core/init.c there's an error: #if !MEMP_MEM_MALLOC && PBUF_POOL_SIZE && (TCP_WND > (PBUF_POOL_SIZE * (PBUF_POOL_BUFSIZE - (PBUF_LINK_ENCAPSULATION_HLEN + PBUF_LINK_HLEN + PBUF_IP_HLEN + PBUF_TRANSPORT_HLEN #error "lwip_sanity_check: WARNING: TCP_WND is larger than space provided by PBUF_POOL_SIZE * (PBUF_POOL_BUFSIZE - protocol headers). If you know what you are doing, define LWIP_DISABLE_TCP_SANITY_CHECKS to 1 to disable this error." #endif Yes, that's room for improvement :-) You probably don't need to buffer a complete TCP_WND in the rx pbufs as I suppose mbedtls just copies the data into its buffers until a whole message is received... Regards, Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] altcp_tls_mbedtls
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: [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 maximum of them (of course, I hope to compare it with OUT buffer only, because it is smaller). I think you're right: this should compare to the IN buffer. No that it would help you here... :-) I'm not an expert here, so my question could be very stupid. TCP_WND is the TCP window that is used to avoid continuous ack for small data. The transmitter sends data filling the window and then waits for the ack. TCP_WND is what we announce to the remote host to be able to buffer for RX. For TX, what we buffer is the minimum of what the remote host tells us to be able to buffer and the memory we have/allow (both available heap memory and the limitation defines SND_BUF and SND_QUEUE_LEN). Ok, but I couldn't understand the relation between lwip receiving window and TLS incoming buffer. If MBEDTLS_SSL_IN_CONTENT_LEN is 16kB, should I need a TCP_WND at least 16kB, for a total of 32kB of memory only to handle incoming TLS traffic? 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 received and ACKed, then the TLS adaption layer passes it into mbedtls and frees the buffer. However, the window update is sent by the application code that is TLS-agnostic. So the window update is only sent after the block has been decrypted. Could you point me to the code that reopen the window after the block has been decrypted? I couldn't find it, my shame. Isn't possible to reopen the window (call tcp_recved) even when a partial TLS block is received? I couldn't understand why lwip needs to reopen the window only when an entire block is received (and decrypted by mbedTLS). Suppose 1kB of a 16kB encrypted block is received, altcp_tls_mbedtls pass the data to the application mbedTLS that copy them in its buffer, then frees the received pbufs. Now we can reopen the window. What's wrong with this approach that can keep TCP_WND small? And since such a block may be up to 16 kByte, the tcp window has to be at least that big, too, or you can get a deadlock. Suppose I have a TCP_WND of only 2kB and incoming TLS buffer of 16kB. The TLS transmitter could send maximum 2kB of data that are buffered in the lwip receiving window. lwip calls altcp_recv(), so altcp_mbedtls_lower_recv() with received data (2kB maybe segmented in small pbufs and pbuf chains). I can't follow the code, but I expect those data are immediately passed to mbedTLS library that should copy those data to its 16kB incoming buffer, freeing receiving window. I think the lwip TCP receiving window could be smaller than mbedTLS incoming data buffer. To make the receiving window smaller, you'd have to change the code. However, you would gain nothing: TCP_WND is *not* a buffer. The actual buffer is in mbedtls and you can't shrink that. TCP_WND just describes this behaviour. TCP_WND isn't a buffer, however I need to reserve a sufficiently sized memory pools (I'm using memory pools for pbufs with MEMP_MEM_MALLOC=0). And memory pools are statically allocated memory, so I end up with 16kB allocated buffer for mbedTLS and 16kB memory pools for storing at least TCP_WND bytes. In core/init.c there's an error: #if !MEMP_MEM_MALLOC && PBUF_POOL_SIZE && (TCP_WND > (PBUF_POOL_SIZE * (PBUF_POOL_BUFSIZE - (PBUF_LINK_ENCAPSULATION_HLEN + PBUF_LINK_HLEN + PBUF_IP_HLEN + PBUF_TRANSPORT_HLEN #error "lwip_sanity_check: WARNING: TCP_WND is larger than space provided by PBUF_POOL_SIZE * (PBUF_POOL_BUFSIZE - protocol headers). If you know what you are doing, define LWIP_DISABLE_TCP_SANITY_CHECKS to 1 to disable this error." #endif I understand pbuf pool should be sized at least TCP_WND that is 16kB... and pools are statically allocated. Am I wrong? The only downside I see is that this way, all other non-TLS applications get a bigger TCP_WND too. That's why we want to add code to control TCP_WND at runtime per pcb. Yes, this is another useful thing. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] lwIP trouble
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 still have occasional faults,
I decided to upgrade. The application is an http_server that
uses netconn API.
Now, I have also upgraded the FreeRTOS, which went relatively
trouble free.
WithlwIPIfirsthitthenew #ifdef in
netconn_write_vectors_partly:
#if LWIP_SO_SNDTIMEO
if (conn->send_timeout != 0) {
dontblock = 1;
}
#endif /* LWIP_SO_SNDTIMEO */
if (dontblock && !bytes_written) {
/* This implies netconn_write() cannot be used for non-blocking send, since
it has no way to return the number of bytes written. */
return ERR_VAL;
}
I was using netconn_write() macro, and so it was exiting
here with ERR_VAL.
I switched to netconn_write_partly() and it made things work,
sort of. I'm testing the access of a single file. It works
about 90% of the time, but the other 10% it explodes in a
strange way.
Here is the log file.
Netcnn a009879c
http_server_netconn_thread: Sending Message
Netcnn 2 a009879c
http_file_server: Processing Message
netconn_recv...
resource requested = '/s.xml'
tcp_write(), LR = 28a77
tcp_write(pcb=a0098eac, data=10003160, len=68, apiflags=1)
tcp_write: queueing 1b1c:1b60
tcp_output_segment: 1b1c:1b60
XML Generated 2000 bytes
calling netconn_write_partly 36
tcp_write(), LR = 28a77
tcp_write(pcb=a0098eac, data=1000c2c0, len=1460, apiflags=1)
tcp_write: queueing 1b60:2114
tcp_output_segment: 1b60:2114
calling netconn_write_partly 37
tcp_write(), LR = 28a7tcp_write(), LR = 28a77
tcp_write(pcb=a0098eac, data=1000c874, len=540, apiflags=1)
tcp_write: queueing 2114:2330
tcp_output_segment: 2114:2330
7
tcp_write(pcb=a0098eac, data=1000c874, len=540, apiflags=1)
tcp_write: queueing 2330:254c
HARD FAULT
_CFSR 8200
_BFAR 18
LR 2022d
Ihave added the * manually to demark the
intervening call. What I see is that in
the middle of the tcp_write execution another call of
tcp_write comes in with exactly the same parameters.
Presumably to send the same piece of data. I've added
printing LR register at the entry into tcp_write to see there
it is called from. Both calls come from the same location
(api_msg.c:1712). Now I'm kind out of ideas. Any pointers
where to look at would be appreciated.
attached are my config files.
Thank you, Slava
--
Slava Zilberfayn mailto:szil...@home-electro.com
Phone: 416 7289367
Home Electronics, www.home-electro.com
100 Drumlin Circle,
Suite 205
Concord, ON, L4K 3E6
CANADA/*
FreeRTOS V4.6.1 - Copyright (C) 2003-2005 Richard Barry.
This file is part of the FreeRTOS distribution.
FreeRTOS is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
FreeRTOS is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with FreeRTOS; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
Re: [lwip-users] Debugging a hang in an lwIP-based application
> 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/twice in an hour or something like that). The hardware > side of the connection in my case is pretty simple - my PC is connected > with a cable to a router, which is connected with a cable to a switch, > which is then connected with a cable to the devices (there are four of > them). I have very little experience with debugging network > connections, so I would like to ask whether this (low) amount of > retransmissions and duplicated ACKs is something normal/expected or > rather something I should worry about, as any number higher than zero > is a symptom of some problem? > Such a rare occurrence is quite normal, but if you have a port mirroring on the switch, then there will be many such duplicates. -- pozdrawiam tomek ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] altcp_tls_mbedtls
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 warning correct? I think TCP_WND should be compared with > MBEDTLS_SSL_IN_CONTENT_LEN or MBEDTLS_SSL_OUT_CONTENT_LEN or the > maximum > of them (of course, I hope to compare it with OUT buffer only, because > it is smaller). > >>> I think you're right: this should compare to the IN buffer. No that it > >>> would help you here... :-) > >> > >> I'm not an expert here, so my question could be very stupid. TCP_WND is > >> the TCP window that is used to avoid continuous ack for small data. The > >> transmitter sends data filling the window and then waits for the ack. > > > > TCP_WND is what we announce to the remote host to be able to buffer > > for RX. > > > > For TX, what we buffer is the minimum of what the remote host tells us > > to be able to buffer and the memory we have/allow (both available heap > > memory and the limitation defines SND_BUF and SND_QUEUE_LEN). > > Ok, but I couldn't understand the relation between lwip receiving window > and TLS incoming buffer. If MBEDTLS_SSL_IN_CONTENT_LEN is 16kB, should I > need a TCP_WND at least 16kB, for a total of 32kB of memory only to > handle incoming TLS traffic? 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 received and ACKed, then the TLS adaption layer passes it into mbedtls and frees the buffer. However, the window update is sent by the application code that is TLS-agnostic. So the window update is only sent after the block has been decrypted. And since such a block may be up to 16 kByte, the tcp window has to be at least that big, too, or you can get a deadlock. > Suppose I have a TCP_WND of only 2kB and incoming TLS buffer of 16kB. > The TLS transmitter could send maximum 2kB of data that are buffered in > the lwip receiving window. lwip calls altcp_recv(), so > altcp_mbedtls_lower_recv() with received data (2kB maybe segmented in > small pbufs and pbuf chains). > > I can't follow the code, but I expect those data are immediately passed > to mbedTLS library that should copy those data to its 16kB incoming > buffer, freeing receiving window. I think the lwip TCP receiving window > could be smaller than mbedTLS incoming data buffer. To make the receiving window smaller, you'd have to change the code. However, you would gain nothing: TCP_WND is *not* a buffer. The actual buffer is in mbedtls and you can't shrink that. TCP_WND just describes this behaviour. The only downside I see is that this way, all other non-TLS applications get a bigger TCP_WND too. That's why we want to add code to control TCP_WND at runtime per pcb. Regards, Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
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 warning correct? I think TCP_WND should be compared with MBEDTLS_SSL_IN_CONTENT_LEN or MBEDTLS_SSL_OUT_CONTENT_LEN or the maximum of them (of course, I hope to compare it with OUT buffer only, because it is smaller). I think you're right: this should compare to the IN buffer. No that it would help you here... :-) I'm not an expert here, so my question could be very stupid. TCP_WND is the TCP window that is used to avoid continuous ack for small data. The transmitter sends data filling the window and then waits for the ack. TCP_WND is what we announce to the remote host to be able to buffer for RX. For TX, what we buffer is the minimum of what the remote host tells us to be able to buffer and the memory we have/allow (both available heap memory and the limitation defines SND_BUF and SND_QUEUE_LEN). Ok, but I couldn't understand the relation between lwip receiving window and TLS incoming buffer. If MBEDTLS_SSL_IN_CONTENT_LEN is 16kB, should I need a TCP_WND at least 16kB, for a total of 32kB of memory only to handle incoming TLS traffic? Suppose I have a TCP_WND of only 2kB and incoming TLS buffer of 16kB. The TLS transmitter could send maximum 2kB of data that are buffered in the lwip receiving window. lwip calls altcp_recv(), so altcp_mbedtls_lower_recv() with received data (2kB maybe segmented in small pbufs and pbuf chains). I can't follow the code, but I expect those data are immediately passed to mbedTLS library that should copy those data to its 16kB incoming buffer, freeing receiving window. I think the lwip TCP receiving window could be smaller than mbedTLS incoming data buffer. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Again confused about tcp_recved() and pbuf_free()
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 think the > >> application should call tcp_recved(). > > > > If you need to process the received data further at slower speed, it's > > better to not call tcp_recved() right away. For example if you're > > programming into slow flash, calling tcp_recved after the bytes are > > programmed ensures the client does not send faster than you can program. > > In this case you don't free the pbuf, because data is being written to > the Flash. So it seems to me that when you free the pbuf (you have > processed the incoming data), you can call tcp_recved(). If you don't > free the pbuf, you haven't processed the data yet, so you don't call > tcp_recved(). > > I don't understand when the two things can be different. They might be the same for you. But if you have a different buffering scheme (e.g. a ring buffer for flash writes or whatever), it could be different. With a library like lwIP, you just don't know how it will be used in the actual targets. Regards, Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Again confused about tcp_recved() and pbuf_free()
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 the receiver: "The purpose is to advertise a larger window when the data has been processed.". Isn't the TCP window size fixed to TCP_WND macro? Does it mean that the window size increases every time tcp_recved() is called from the application? I don't think, otherwise the window size increases continuously during a connection. The window has a more or less fixed total size. But it changes with each segment sent: for every byte sent (and ACKed), it decrease. The receiver is responsible to "reopen" the window by sending an appropriate window size with its ACK segments. lwIP does this for you, but you have to tell it when you are ready to accept more data. This is what 'tcp_recved()' does. 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 think the application should call tcp_recved(). If you need to process the received data further at slower speed, it's better to not call tcp_recved() right away. For example if you're programming into slow flash, calling tcp_recved after the bytes are programmed ensures the client does not send faster than you can program. In this case you don't free the pbuf, because data is being written to the Flash. So it seems to me that when you free the pbuf (you have processed the incoming data), you can call tcp_recved(). If you don't free the pbuf, you haven't processed the data yet, so you don't call tcp_recved(). I don't understand when the two things can be different. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Using LWIP with PPP and NAT
> 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 > have still made it into rt-thread... > > So you can either assume that the two above have talked to Christian > Walter and cleared up the licensing issue or they aren't aware of this > fact or they don't care :-) > > I just wanted to point this out on this list to ensure we're not to > blame. > > > Regards, > Simon > I completely understand your point. And for sure lwIP is not to blame at all. I clearly mentioned in my repo that NAT source is not part of lwIP. Moreover, It may sound odd but I think I may have found the "real" Christian Walter, the author of lwip_nat source. I also emailed him to know more and just hoping he responds back. Well the attribution is there and I am not sure who's to blame. Not me hopefully :-P Regards, Ajay Bhargav ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
