Bug 156785

As a personal test here, I modified the sctp_darn utility to subscribe to
shutdown notifications, so that when operating in receive mode, it would bail
out in test_verify_assoc_change, printing the notification type and exiting on
shutdown, when a shutdown event was recieved from it peer (assuming that the
notification was in fact delivered to userspace, which I did not expect, given
this bug report).  When I ran two interactive sctp_darn sessions (one in send
mode, the other in listen), with this modification, I sent a shutdown from the
send side, and was suprised to see the listening side bail out, printing an
indication that it had received an "unknown" notification (one other than the
SCTP_ASSOC_CHANGE that it expected).  The utility printed the notification type,
which was sn_type=32773.  This appears to be the defined value for
SCTP_SHUTDOWN_EVENT.  So it would appear that as long as the the peer socket is
shutdown cleanly, shutdown notifications are properly received.  If I repeat the
test and exit the sending peer with a ctrl-c or a kill -9, I get the same
results.  So I'm unable to reproduce this misssing shutdown notification using
my test setup.  Can you please confirm this?  I'm currently using the 2.6.9-17
RHEL4 kernel, and the sctp_darn utility from lksctp-tools-1.0.2-6.4E.1, modified
to subscribe to shutdown notifications in with this patch:
--- lksctp-tools-1.0.2/src/apps/sctp_darn.c.orig        2005-09-09
16:34:08.000000000 -0400
+++ lksctp-tools-1.0.2/src/apps/sctp_darn.c     2005-09-09 16:34:24.000000000 -0400
@@ -476,6 +476,7 @@ build_endpoint(char *argv0, int portnum)
                memset(&subscribe, 0, sizeof(subscribe));
                subscribe.sctp_data_io_event = 1;
                subscribe.sctp_association_event = 1;
+               subscribe.sctp_shutdown_event = 1;
                error = setsockopt(retval, SOL_SCTP, SCTP_EVENTS,
                                   (char *)&subscribe, sizeof(subscribe));
                if (error) {

Re-tested with kernel 2.6.9-17.TEST.IT79426smp (should be no different from 
plain 2.6.9-17 in this case, right?) and sctp_darn from lksctp-tools-1.0.2-
6.4E.1 with Neil's patch from comment #5. Results were identical with my first 
description.

Neil, if you were able to successfully send the shutdown, I guess you were 
using SOCK_SEQPACKET at least on the client side. Sending shutdown doesn't 
appear to be working with SOCK_STREAM sockets. Please double-check that you're 
using SOCK_STREAM on the server side. SHUTDOWN notification works correctly 
with SOCK_SEQPACKET, this problem exists only with SOCK_STREAM sockets.

Jere,

2.6.9-17.TEST.IT79426smp is not a kernel I built, so I cannot comment. Please do
test with plain 2.6.9-17.

Kind regards,

Patrick

Re-tested with kernel 2.6.9-17.ELsmp and sctp_darn from lksctp-tools-1.0.2-
6.4E.1 with Neil's patch from comment #5. Again, results were identical with my 
first description.

Ok, I see the behavior now.  I think this may be because in
sctp_sf_do_9_2_shutdown, we add the command to transition state to
SCTP_STATE_SHUTDOWN_RECEIVED before we add the command to queue the SHUTDOWN
ulpevent to the recieve queue.  This causes sctp_cmd_new_state to run in the
state machine first, setting the RCV_SHUTDOWN state on the socket.  Later, for
tcp sytle sockets in sctp_ulpq_tail_event (where the ulpevent is queued), we
check for the RCV_SHUTDOWN flag, and if its set, we drop the frame.  I'm going
to work up a patch that adds the state transition command to the state machine
after the queue command for testing.

Created attachment 119153 [details]
backport of my upstream proposal to allow tcp style sctp sockets get shutdown notices

Heres a backport of the patch I'm proposing upstream to queue shutdown
notifications to the socket receive queue prior to shutting down the socket.

Created attachment 119171 [details]
corrected patch w/ upstream revisions

This is the final upstream version of the patch, taking into account sri's
suggestion changes for the things I broke in the process of fixing the
origional problem :)

Re-tested with the latest patch and it's working now, I'm getting SHUTDOWN 
correctly. Good job.

Thanks, This has been accepted upstream, so I'll post internally today.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2006-0132.html