Turns out we would reset the TSN seq counter during

a colliding INIT. This if fine except when we have
data outstanding... we basically reset it to the
previous value it was.. so then we end up assigning
the same TSN to two different data chunks.
This patch:

1) Finds a missing lock for when we change the stream
   numbers during COOKIE and INIT-ACK processing.. we
   were NOT locking the send_buffer.. which COULD cause
   problems (found by inspection looking for <2>)

2) Fixes a case during a colliding INIT where we incorrectly
   reset the sending Sequence thus in some cases duplicately
   assigning a TSN.

3) Additional enhancments to logging so we can see strm/tsn in
   the receiver AND new tracking to watch what the sender
   is doing with TSN and STRM seq's.

Approved by:	gnn

1 files changed, 1 insertions, 1 deletions

diff --git a/sys/netinet/sctputil.h b/sys/netinet/sctputil.h
index 7f0d429..ef0e9a4 100644
--- a/sys/netinet/sctputil.h
+++ b/sys/netinet/sctputil.h
@@ -265,7 +265,7 @@ sctp_wakeup_log(struct sctp_tcb *stcb,
     uint32_t cumtsn,
     uint32_t wake_cnt, int from);
 
-void sctp_log_strm_del_alt(uint32_t, uint16_t, int);
+void sctp_log_strm_del_alt(struct sctp_tcb *stcb, uint32_t, uint16_t, uint16_t, int);
 
 void sctp_log_nagle_event(struct sctp_tcb *stcb, int action);