On Thu, Jan 5, 2017 at 4:43 PM, Joel Cunningham
wrote:
>
> RAW_PCB exhaustion is most likely unrelated to the problem you’re seeing.
> When TCP segments are allocated in tcp_write() (with TCP_WRITE_FLAG_COPY
> specified) there are two allocations: PBUF_RAM (coming from
> On Jan 3, 2017, at 9:34 AM, Daniel Pauli wrote:
>
> If you have LwIP stats enabled, you can check the memory pools for errors to
> figure out which one is failing. You should be able to resolve this by
> sizing your memory pools to handle the number of supported
>
> If you have LwIP stats enabled, you can check the memory pools for errors
> to figure out which one is failing. You should be able to resolve this by
> sizing your memory pools to handle the number of supported connections.
> For example if you only support 5 simultaneous TCP connections,
> On Dec 30, 2016, at 12:59 PM, Daniel Pauli wrote:
>
> Many thanks for your advice! I'll try to check the memory pools when I
> reproduce the issue next time.
>
> Further, since it sounds like you initially had sockets configured in
> blocking mode, when the new socket
Many thanks for your advice! I'll try to check the memory pools when I
reproduce the issue next time.
Further, since it sounds like you initially had sockets configured in
> blocking mode, when the new socket tries to transmit, it will block trying
> to allocate TCP segments due to the exhausted
> On Dec 30, 2016, at 10:43 AM, Daniel Pauli wrote:
>
> I'm a little confused about the use of select in your application. Are you
> using it with blocking sockets?
>
> I tested with both blocking and non-blocking send. I observed that
> non-blocking send (MSG_DONTWAIT
>
> I'm a little confused about the use of select in your application. Are
> you using it with blocking sockets?
I tested with both blocking and non-blocking send. I observed that
non-blocking send (MSG_DONTWAIT flag set) on sockets determined as
write-ready by select() sometimes returned
On Dec 28, 2016, at 06:45 AM, Daniel Pauli wrote:
Am I understanding the description correctly that sending on the stale
connection eventually blocks once the remote side has crashed and this prevents
sending on the new socket (only because the thread is blocked)?
--
> I guess lwIP could get a hint and recover (quite) faster if it got RST for
> response instead of silence. Try without the firewall in between.
> Nevertherless,
> can you please post a capture file so we can get the whole picture ? I
> think you have a memory hog
>
> Am I understanding the description correctly that sending on the stale
> connection eventually blocks once the remote side has crashed and this
> prevents sending on the new socket (only because the thread is blocked)?
>
> If so, then the socket buffer on the stale socket has filled up (most
>
Am I understanding the description correctly that sending on the stale
connection eventually blocks once the remote side has crashed and this prevents
sending on the new socket (only because the thread is blocked)?
If so, then the socket buffer on the stale socket has filled up (most likely)
I guess lwIP could get a hint and recover (quite) faster if it got RST
for response instead of silence. Try without the firewall in between.
Nevertherless, can you please post a capture file so we can get the
whole picture ? I think you have a memory hog problem and you need to
detect/recover
Hey there
I have a TCP client running on a Windows PC that communicates with a TCP
server on a LWIP box. The client sends requests to the server in high
frequency (polling) and receives responses of approx. 16 KB.
The problem: When a clients crashes (without being able to send FIN/RST
13 matches
Mail list logo