laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmo-netif/+/38004?usp=email )
Change subject: src/stream.c: Use sctp_assoc_id 'canary' to detect misisng sinfo ......................................................................
src/stream.c: Use sctp_assoc_id 'canary' to detect misisng sinfo
sctp_rcvinfo() has a successful return path that does *not* fill the caller-provided sinfo structure. This would be highly unexpected as we cannot determine the stream_id and PPID then.
Our osmo_io code path already handles that situation correctly by logging a related error message. The non-osmo-io path however would silently hide that error.
See also: https://github.com/sctp/lksctp-tools/issues/37
Change-Id: Idf9c0fa4db65ab6ea34a9cb2011400aadf3dd54e --- M src/stream.c 1 file changed, 7 insertions(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/libosmo-netif refs/changes/04/38004/1
diff --git a/src/stream.c b/src/stream.c index f8cbed6..5033f4c 100644 --- a/src/stream.c +++ b/src/stream.c @@ -279,8 +279,14 @@ int flags = 0; int ret;
+ /* Canary to detect if kernel returns sinfo; see https://github.com/sctp/lksctp-tools/issues/37 */ + sinfo.sinfo_assoc_id = 0; + ret = sctp_recvmsg(fd, msg->tail, msgb_tailroom(msg), NULL, NULL, &sinfo, &flags); - return stream_sctp_recvmsg_trailer(log_pfx, msg, ret, &sinfo, flags); + if (sinfo.sinfo_assoc_id) + return stream_sctp_recvmsg_trailer(log_pfx, msg, ret, &sinfo, flags); + else + return stream_sctp_recvmsg_trailer(log_pfx, msg, ret, NULL, flags); }
/*! wrapper for osmo_io asynchronous recvmsg response */