On 2022-11-30 18:27, Pablo Neira Ayuso wrote: > On Fri, Nov 04, 2022 at 06:18:35PM +0100, Sriram Yagnaraman wrote: >> Changes since v2: >> - Abandoned the sctp no_random_port patch from the series >> >> SCTP conntrack currently assumes that the SCTP endpoints will >> probe secondary paths using HEARTBEAT before sending traffic. >> >> But, according to RFC 9260, SCTP endpoints can send any traffic >> on any of the confirmed paths after SCTP association is up. >> SCTP endpoints that sends INIT will confirm all peer addresses >> that upper layer configures, and the SCTP endpoint that receives >> COOKIE_ECHO will only confirm the address it sent the INIT_ACK to. >> >> So, we can have a situation where the INIT sender can start to >> use secondary paths without the need to send HEARTBEAT. This patch >> allows DATA/SACK packets to create new connection tracking entry. >> >> A new state has been added to indicate that a DATA/SACK chunk has >> been seen in the original direction - SCTP_CONNTRACK_DATA_SENT. >> State transitions mostly follows the HEARTBEAT_SENT, except on >> receiving HEARTBEAT/HEARTBEAT_ACK/DATA/SACK in the reply direction. >> >> State transitions in original direction: >> - DATA_SENT behaves similar to HEARTBEAT_SENT for all chunks, >> except that it remains in DATA_SENT on receving HEARTBEAT, >> HEARTBEAT_ACK/DATA/SACK chunks >> State transitions in reply direction: >> - DATA_SENT behaves similar to HEARTBEAT_SENT for all chunks, >> except that it moves to HEARTBEAT_ACKED on receiving >> HEARTBEAT/HEARTBEAT_ACK/DATA/SACK chunks >> >> Note: This patch still doesn't solve the problem when the SCTP >> endpoint decides to use primary paths for association establishment >> but uses a secondary path for association shutdown. We still have >> to depend on timeout for connections to expire in such a case. > Applied, thanks > > One request of mine: Would you send a patch to extend > > Documentation/networking/nf_conntrack-sysctl.rst > > to document sctp timeouts? > > Thanks. Yes, sure will do.
