From 96271688cfd1da5ca693d0a20a87cd499b8d9e8a Mon Sep 17 00:00:00 2001 From: Pau Espin Pedrol Date: Fri, 30 Sep 2022 14:26:02 +0200 Subject: [PATCH] stream: Return 0 when receiving sctp notification SCTP_COMM_LOST It was seen on a real pcap trace (sctp & gsmtap_log) that the Linux kernel stack may decide to kill the connection (sending an ABORT) if it fails to transmit some data after a while: ABORT Cause code: "Protocol violation (0x000d)", Cause Information: "Association exceeded its max_retrans count". When this occurs, the kernel sends the MSG_NOTIFICATION,SCTP_ASSOC_CHANGE,SCTP_COMM_LOST notification when reading from the socket with sctp_recvmsg(). This basically signals that the socket conn is dead, and subsequent writes to it will result in send() failures (and receive SCTP_SEND_FAILED notification upon follow up reads). It's important to notice that after those events, there's no other sort of different event like SHUTDOWN coming in, so that's the time at which we must tell the user to close the socket. Hence, let's signal the caller that the socket is dead by returning 0, to comply with usual recv() API. Related: SYS#6113 Change-Id: If94d44f25b76a96a5ea402fec9fc14c4e6296ba3 --- src/stream.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/stream.c b/src/stream.c index 5e15142..38d24fe 100644 --- a/src/stream.c +++ b/src/stream.c @@ -1490,7 +1490,8 @@ static int _sctp_recvmsg_wrapper(int fd, struct msgb *msg) break; case SCTP_COMM_LOST: LOGPC(DLINP, LOGL_DEBUG, " LOST\n"); - break; + /* Handle this like a regular disconnect */ + return 0; case SCTP_RESTART: LOGPC(DLINP, LOGL_DEBUG, " RESTART\n"); break;