[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Issue with "blocked" pcbs
From: |
Klaus Breining |
Subject: |
[lwip-users] Issue with "blocked" pcbs |
Date: |
Sun, 27 Dec 2020 19:18:18 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 |
Hello,
I am using a (modified) version of the http-server in the apps directory
using application layer tcp (altcp_*). Before I was directly using the
tcp callback api, but to use mbedtls, I have changed the tcp-calls to
altcp-calls and compared the logic line-by-line with the sample code to
check, if the sequence of calls is identical.
Using tcp-calls I never had issues. Even under heavy load there are no
memory leaks and all tcp_pcbs are freed after some time even when I
brutally kill connections in different ways.
Using altcp-calls, after some time (sometimes hours, sometimes I can
create the situation after minutes) all tcp_pcbs are blocked. To get
fast into the situation, I have set
#define MEMP_NUM_TCP_PCB 4
#define MEMP_NUM_ALTCP_PCB 11
This is the situation after some time: (Flag C => TF_RXCLOSED, Flag
F=>TF_FIN)
-------- PCB list --------
active 0x2000ca1c: 192.168.10.23:80 (CF 4 5)
active 0x2000cacc: 192.168.10.23:80 (CF 4 5)
active 0x2000cb7c: 192.168.10.23:80 (CF 4 5)
active 0x2000c96c: 192.168.10.23:80 (CF 4 5)
listen 0x2000dbf8: 0.0.0.0:80
listen 0x2000dbd8: 0.0.0.0:443
--------------------------
The numbers in brackets are the last max. 16 states of the pcb, here
ESTABLISHED -> FIN_WAIT_1
Now all tcp_pcbs are hanging in FIN_WAIT_1. This state is not handled in
tcp_slowtmr(). The only function which handles this state is
tcp_process(), but obviously there are situations in which either
tcp_process() for this pcb_state is never called or in which in the
state-handler is doing nothing (which means, that neither TF_GOT_FIN nor
TCP_ACK are set).
I assume that this is not an issue of the altcp-API but a timing issue.
I am using a quite slow CPU (Texas Instruments Tiva TM4C129 with quite
small RAM (256kByte) for TLS-usage.
Does anyone have an idea, how the system gets into this state (and more
important, how to get out of it :) )?
Regards
Klaus
- [lwip-users] Issue with "blocked" pcbs,
Klaus Breining <=