Hello,
On 2020-12-29 20:07, Klaus Breining wrote:
I have seen the following sequence:
- Receive SYN
- Answer SYN/ACK
- Receive ACK
Up to now everything is normal. Here altcp_tcp_accept() is called.
PCB is ESTABLISHED
- Receive PSH/ACK
- Answer PSH/ACK
- Receive ACK
- Send FIN/PSH/ACK
- Receive RES/ACK
Reset processing ends up in tcp_ack_now(), the flag acceptable is not
set. The function tcp_process() returns ERR_OK without doing anything
with the PCB.
How this PCB will ever disappear? It is now in state FIN_WAIT_1 with
flags TF_RXCLOSED | TF_FIN. The PCB will never receive anything again
and the slow timer tcp_slowtmr() is the only function that could
change the state of a PCB - but it only resends the last FIN/PSH/ACK
package every few seconds to a port which obviously the browser on the
other side has already closed.
For TCP, closing one end of the connection does not imply that the
other end is closed too. If the other side doesn't also close the
connection then you end up in your situation.
Normally the application closes the socket when receiving a FIN
(tcp_recv_fn will be called with a NULL pbuf if the connection is
closed). An extra complication is that if you have data queued
for transmit, you probably want to finish sending that first
before actually closing the connection.
TLS has the added complication that it first needs to decode
and handle all encrypted data before it can pass the FIN to
the application layer, see altcp_mbedtls_lower_recv(). In this
corner case ALTCP_MBEDTLS_FLAGS_RX_CLOSE_QUEUED will be set
and later handled in altcp_mbedtls_pass_rx_data(), which is
called periodically by the polling function. As far as I can
tell the current altcp code is correct in this regard. Same
for http_close_or_abort_conn().
Does your modified version also has error handling for the
altcp_close() call? (Similar polling approach or calling
altcp_abort() on error.) If not, the call may fail when low
on memory and if your application code does nothing you will
stay in this state forever.
Greetings,
Indan
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users