[SCTP] Initialization collision problem

[SCTP] Initialization collision problem

[Isaula Oscar-QOI000]

[-- Attachment #1: Type: text/plain, Size: 2698 bytes --]

I ran into a problem where LKSCTP is reporting a SCTM_COMM_UP indication
to the User application but is giving back a value of zero for the
assoc_id.

Attached are the SCTP debugs for the period in question.

A couple of things that I would like to note about my setup. One is that
I'm running Kernel version 2.6.10 (I know is old but I can't move to a
newer version due to custom drivers). The second thing is that the link
between the two SCTP node is a very noisy and some messages are getting
lost (i.e. the INIT_ACK from the peer in this particular case).

After analyzing the SCTP code I came out with the following code
changes:

--- sm_statefuns.c.old  2007-04-04 08:58:34.074606000 -0500
+++ sm_statefuns.c.new  2007-04-04 09:03:31.818426000 -0500
@@ -1515,7 +1515,7 @@
  */
 /* This case represents an initialization collision.  */
 static sctp_disposition_t sctp_sf_do_dupcook_b(const struct
sctp_endpoint *ep,
-                    const struct sctp_association *asoc,
+                    struct sctp_association *asoc,
                     struct sctp_chunk *chunk,
                     sctp_cmd_seq_t *commands,
                     struct sctp_association *new_asoc)
@@ -1528,13 +1528,13 @@
      * side effects--it is safe to run them here.
      */
     peer_init = &chunk->subh.cookie_hdr->c.peer_init[0];
-    if (!sctp_process_init(new_asoc, chunk->chunk_hdr->type,
+    if (!sctp_process_init(asoc, chunk->chunk_hdr->type,
                    sctp_source(chunk), peer_init,
                    GFP_ATOMIC))
         goto nomem;
 
     /* Update the content of current association.  */
-    sctp_add_cmd_sf(commands, SCTP_CMD_UPDATE_ASSOC,
SCTP_ASOC(new_asoc));
+    sctp_add_cmd_sf(commands, SCTP_CMD_UPDATE_ASSOC, SCTP_ASOC(asoc));
     sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
             SCTP_STATE(SCTP_STATE_ESTABLISHED));
     SCTP_INC_STATS(SCTP_MIB_CURRESTAB);
@@ -1554,8 +1554,8 @@
      * upon reception of a valid COOKIE ECHO chunk.
      */
     ev = sctp_ulpevent_make_assoc_change(asoc, 0, SCTP_COMM_UP, 0,
-                         new_asoc->c.sinit_num_ostreams,
-                         new_asoc->c.sinit_max_instreams,
+                         asoc->c.sinit_num_ostreams,
+                         asoc->c.sinit_max_instreams,
                          GFP_ATOMIC);
     if (!ev)
         goto nomem_ev;

-----------------------------------------

I can't say that I'm an expert on this area so I'm hoping someone in the
list can provide some feedback. The change has been tested and it fixes
the original problem and we have not detected any side effects so far.

Thanks,
Oscar





[-- Attachment #2: initLog.txt --]
[-- Type: text/plain, Size: 9759 bytes --]

Mar 30 19:47:45 localhost kernel: +++sctp_inq_pop+++ chunk cede2460[ABORT], length 8, skb->len 4
Mar 30 19:47:45 localhost kernel: sctp_do_sm prefn: ep d0ede960, EVENT_T_CHUNK, ABORT, asoc ce366000[STATE_ESTABLISHED], sctp_sf_do_9_1_abort
Mar 30 19:47:45 localhost kernel: sctp_do_sm postfn: asoc ce366000, status: DISPOSITION_ABORT
Mar 30 19:47:45 localhost kernel: sm_sideff: event_up: ce6a3338, ulpq: ce36741c.
Mar 30 19:47:45 localhost kernel: sctp_do_sm post sfx: error 0, asoc ce366000[STATE_CLOSED]
Mar 30 19:47:45 localhost kernel: sctp_sendmsg(sk: dfcdf320, msg: d0a19ea0, msg_len: 8)
Mar 30 19:47:45 localhost kernel: Using endpoint: unnamedEndpoint.
Mar 30 19:47:45 localhost kernel: Just memcpy'd. msg_name is 0xa962018:51000.
Mar 30 19:47:45 localhost kernel: msg_len: 8, sinfo_flags: 0x0
Mar 30 19:47:45 localhost kernel: About to look up association.
Mar 30 19:47:45 localhost kernel: There is no association yet.
Mar 30 19:47:45 localhost kernel: myctsnap for unnamedEndpoint INIT as 0xb693faae.
Mar 30 19:47:45 localhost kernel: sctp_v4_get_dst: DST:XX.XX.XX.24, SRC:0.0.0.0 - <7>rt_dst:XX.XX.XX.24, rt_src:XX.XX.XX.109
Mar 30 19:47:45 localhost kernel: sctp_assoc_add_peer:association ce01c000 PMTU set to 512
Mar 30 19:47:45 localhost kernel: sctp_packet_init: packet:d4e81ce4 transport:d4e81c00
Mar 30 19:47:45 localhost kernel: We have a valid association.
Mar 30 19:47:45 localhost kernel: sctp_do_sm prefn: ep d0ede960, EVENT_T_PRIMITIVE, PRIMITIVE_ASSOCIATE, asoc ce01c000[STATE_CLOSED], sctp_sf_do_prm_asoc
Mar 30 19:47:45 localhost kernel: sctp_do_sm postfn: asoc ce01c000, status: DISPOSITION_CONSUME
Mar 30 19:47:45 localhost kernel: sctp_outq_tail(ce01d3d8, cede2460[INIT])
Mar 30 19:47:45 localhost kernel: sctp_packet_config: packet:d4e81ce4 vtag:0x0
Mar 30 19:47:45 localhost kernel: sctp_packet_init: packet:d0a19990 transport:d4e81c00
Mar 30 19:47:45 localhost kernel: sctp_packet_config: packet:d0a19990 vtag:0x0
Mar 30 19:47:45 localhost kernel: sctp_packet_append_chunk: packet:d0a19990 chunk:cede2460
Mar 30 19:47:45 localhost kernel: sctp_packet_transmit: packet:d0a19990
Mar 30 19:47:45 localhost kernel: ***sctp_transmit_packet***
Mar 30 19:47:45 localhost kernel: *** Chunk cede2460[INIT] No TSN 0x0, length 44, chunk->skb->len 44, rtt_in_progress 0
Mar 30 19:47:45 localhost kernel: sctp_v4_get_dst: DST:XX.XX.XX.24, SRC:0.0.0.0 - <7>rt_dst:XX.XX.XX.24, rt_src:XX.XX.XX.109
Mar 30 19:47:45 localhost kernel: sctp_assoc_sync_pmtu: asoc:ce01c000, pmtu:512, frag_point:464
Mar 30 19:47:45 localhost kernel: ***sctp_transmit_packet*** skb len 56
Mar 30 19:47:45 localhost kernel: sctp_v4_xmit: skb:ce615e00, len:56, src:XX.XX.XX.109, dst:XX.XX.XX.24
Mar 30 19:47:45 localhost kernel: sctp_do_sm post sfx: error 0, asoc ce01c000[STATE_CLOSED]
Mar 30 19:47:45 localhost kernel: We associated primitively.
Mar 30 19:47:45 localhost kernel: sctp_do_sm prefn: ep d0ede960, EVENT_T_PRIMITIVE, PRIMITIVE_SEND, asoc ce01c000[STATE_COOKIE_WAIT], sctp_sf_do_prm_send
Mar 30 19:47:45 localhost kernel: sctp_do_sm postfn: asoc ce01c000, status: DISPOSITION_CONSUME
Mar 30 19:47:45 localhost kernel: sctp_outq_tail(ce01d3d8, cede2460[DATA])
Mar 30 19:47:45 localhost kernel: outqueueing (ce01d3d8, cede2460[DATA])
Mar 30 19:47:45 localhost kernel: sctp_do_sm post sfx: error 0, asoc ce01c000[STATE_CLOSED]
Mar 30 19:47:45 localhost kernel: We sent primitively.
Mar 30 19:47:45 localhost kernel: sctp_getsockopt(sk: dfcdf320, ...)
Mar 30 19:47:45 localhost kernel: sctp_recvmsg(sk: dfcdf320, msghdr: d0a19e20, len: 1024, knoblauch: 0, flags: 0x0, addr_len: d0a19cb8)
Mar 30 19:47:45 localhost kernel: Timeout: timeo: 2147483647, MAX: 2147483647.
Mar 30 19:47:45 localhost kernel: sctp_recvmsg(sk: dfcdf320, msghdr: d0a19e20, len: 1024, knoblauch: 0, flags: 0x0, addr_len: d0a19cb8)
Mar 30 19:47:45 localhost kernel: Timeout: timeo: 2147483647, MAX: 2147483647.
Mar 30 19:47:45 localhost kernel: sctp_recvmsg(sk: dfcdf320, msghdr: d0a19e20, len: 1024, knoblauch: 0, flags: 0x0, addr_len: d0a19cb8)
Mar 30 19:47:45 localhost kernel: Timeout: timeo: 2147483647, MAX: 2147483647.
Mar 30 19:47:45 localhost kernel: +++sctp_inq_pop+++ chunk cede23a0[INIT], length 32, skb->len 28
Mar 30 19:47:45 localhost kernel: sctp_do_sm prefn: ep d0ede960, EVENT_T_CHUNK, INIT, asoc ce01c000[STATE_COOKIE_WAIT], sctp_sf_do_5_2_1_siminit
Mar 30 19:47:45 localhost kernel: myctsnap for unnamedEndpoint INIT as 0x3acb4214.
Mar 30 19:47:45 localhost kernel: sctp_v4_get_dst: DST:XX.XX.XX.24, SRC:0.0.0.0 - <7>rt_dst:XX.XX.XX.24, rt_src:XX.XX.XX.109
Mar 30 19:47:45 localhost kernel: sctp_assoc_add_peer:association ceffe000 PMTU set to 512
Mar 30 19:47:45 localhost kernel: sctp_packet_init: packet:d4e81ae4 transport:d4e81a00
Mar 30 19:47:45 localhost kernel: sctp_do_sm postfn: asoc ce01c000, status: DISPOSITION_CONSUME
Mar 30 19:47:45 localhost kernel: sctp_outq_tail(cefff3d8, cede2ee0[INIT_ACK])
Mar 30 19:47:45 localhost kernel: sctp_packet_config: packet:d4e81ce4 vtag:0x4c840a08
Mar 30 19:47:45 localhost kernel: sctp_packet_init: packet:dff95a70 transport:d4e81c00
Mar 30 19:47:45 localhost kernel: sctp_packet_config: packet:dff95a70 vtag:0x4c840a08
Mar 30 19:47:45 localhost kernel: sctp_packet_append_chunk: packet:dff95a70 chunk:cede2ee0
Mar 30 19:47:45 localhost kernel: sctp_packet_transmit: packet:dff95a70
Mar 30 19:47:45 localhost kernel: ***sctp_transmit_packet***
Mar 30 19:47:45 localhost kernel: *** Chunk cede2ee0[INIT_ACK] No TSN 0x0, length 196, chunk->skb->len 196, rtt_in_progress 0
Mar 30 19:47:45 localhost kernel: ***sctp_transmit_packet*** skb len 208
Mar 30 19:47:45 localhost kernel: sctp_v4_xmit: skb:ce615d40, len:208, src:XX.XX.XX.109, dst:XX.XX.XX.24
Mar 30 19:47:45 localhost kernel: sctp_packet_free: packet:d4e81ae4
Mar 30 19:47:45 localhost kernel: sctp_do_sm post sfx: error 0, asoc ce01c000[STATE_CLOSED]
Mar 30 19:47:45 localhost kernel: +++sctp_inq_pop+++ chunk cede23a0[COOKIE_ECHO], length 164, skb->len 248
Mar 30 19:47:45 localhost kernel: sctp_do_sm prefn: ep d0ede960, EVENT_T_CHUNK, COOKIE_ECHO, asoc ce01c000[STATE_COOKIE_WAIT], sctp_sf_do_5_2_4_dupcook
Mar 30 19:47:45 localhost kernel: myctsnap for unnamedEndpoint INIT as 0x3acb0879.
Mar 30 19:47:45 localhost kernel: sctp_v4_get_dst: DST:XX.XX.XX.24, SRC:0.0.0.0 - <7>rt_dst:XX.XX.XX.24, rt_src:XX.XX.XX.109
Mar 30 19:47:45 localhost kernel: sctp_assoc_add_peer:association ceffe000 PMTU set to 512
Mar 30 19:47:45 localhost kernel: sctp_packet_init: packet:cebe44e4 transport:cebe4400
Mar 30 19:47:45 localhost kernel: sctp_sf_do_dupcook_b: assoc:0xce01c000 ev:0xce6a3e78
Mar 30 19:47:45 localhost kernel: sctp_do_sm postfn: asoc ce01c000, status: DISPOSITION_CONSUME
Mar 30 19:47:45 localhost kernel: sctp_outq_tail(ce01d3d8, cede2ee0[COOKIE_ACK])
Mar 30 19:47:45 localhost kernel: sctp_packet_config: packet:d4e81ce4 vtag:0x4c840a08
Mar 30 19:47:45 localhost kernel: sctp_packet_transmit_chunk: packet:d4e81ce4 chunk:cede2ee0
Mar 30 19:47:45 localhost kernel: sctp_packet_append_chunk: packet:d4e81ce4 chunk:cede2ee0
Mar 30 19:47:45 localhost kernel: sctp_outq_flush(ce01d3d8, cede2460[DATA]), <7>TX TSN 0x0 skb->head dfa2b160 skb->users 1.
Mar 30 19:47:45 localhost kernel: sctp_packet_transmit_chunk: packet:d4e81ce4 chunk:cede2460
Mar 30 19:47:45 localhost kernel: sctp_packet_append_chunk: packet:d4e81ce4 chunk:cede2460
Mar 30 19:47:45 localhost kernel: sctp_packet_transmit: packet:d4e81ce4
Mar 30 19:47:45 localhost kernel: ***sctp_transmit_packet***
Mar 30 19:47:45 localhost kernel: *** Chunk cede2ee0[COOKIE_ACK] No TSN 0x0, length 4, chunk->skb->len 4, rtt_in_progress 0
Mar 30 19:47:45 localhost kernel: *** Chunk cede2460[DATA] TSN 0xb693faaf, length 24, chunk->skb->len 24, rtt_in_progress 1
Mar 30 19:47:45 localhost kernel: ***sctp_transmit_packet*** skb len 40
Mar 30 19:47:45 localhost kernel: sctp_v4_xmit: skb:ce6a3900, len:40, src:XX.XX.XX.109, dst:XX.XX.XX.24
Mar 30 19:47:45 localhost kernel: sm_sideff: event_up: ce6a3e78, ulpq: ce01d41c.
Mar 30 19:47:45 localhost kernel: sctp_packet_free: packet:cebe44e4
Mar 30 19:47:45 localhost kernel: sctp_do_sm post sfx: error 0, asoc ce01c000[STATE_CLOSED]
Mar 30 19:47:45 localhost kernel: +++sctp_inq_pop+++ chunk cede23a0[DATA], length 88, skb->len 84
Mar 30 19:47:45 localhost kernel: sctp_do_sm prefn: ep d0ede960, EVENT_T_CHUNK, DATA, asoc ce01c000[STATE_ESTABLISHED], sctp_sf_eat_data_6_2
Mar 30 19:47:45 localhost kernel: eat_data: TSN 0xdf97c21d.
Mar 30 19:47:45 localhost kernel: sctp_do_sm postfn: asoc ce01c000, status: DISPOSITION_CONSUME
Mar 30 19:47:45 localhost kernel: sm_sideff: chunk_up: cede23a0, ulpq: ce01d41c.
Mar 30 19:47:45 localhost kernel: sctp_assoc_rwnd_decrease: asoc ce01c000 rwnd decreased by 72 to (108472, 0)
Mar 30 19:47:45 localhost kernel: sackCTSNAck sent:  0xdf97c21d.
Mar 30 19:47:45 localhost kernel: sctp_outq_tail(ce01d3d8, cede2ee0[SACK])
Mar 30 19:47:45 localhost kernel: sctp_packet_config: packet:d4e81ce4 vtag:0x4c840a08
Mar 30 19:47:45 localhost kernel: sctp_packet_transmit_chunk: packet:d4e81ce4 chunk:cede2ee0
Mar 30 19:47:45 localhost kernel: sctp_packet_append_chunk: packet:d4e81ce4 chunk:cede2ee0
Mar 30 19:47:45 localhost kernel: sctp_packet_transmit: packet:d4e81ce4
Mar 30 19:47:45 localhost kernel: ***sctp_transmit_packet***
Mar 30 19:47:45 localhost kernel: *** Chunk cede2ee0[SACK] No TSN 0x0, length 16, chunk->skb->len 16, rtt_in_progress 0
Mar 30 19:47:45 localhost kernel: ***sctp_transmit_packet*** skb len 28
Mar 30 19:47:45 localhost kernel: sctp_v4_xmit: skb:ce615d40, len:28, src:XX.XX.XX.109, dst:XX.XX.XX.24
Mar 30 19:47:45 localhost kernel: sctp_do_sm post sfx: error 0, asoc ce01c000[STATE_CLOSED]

Re: [SCTP] Initialization collision problem

[Vlad Yasevich]

[For SCTP questions, please use netdev or lksctp-developers list]

Hi Oscar

Isaula Oscar-QOI000 wrote:
> I ran into a problem where LKSCTP is reporting a SCTM_COMM_UP indication
> to the User application but is giving back a value of zero for the
> assoc_id.
> 
> Attached are the SCTP debugs for the period in question.
> 
> A couple of things that I would like to note about my setup. One is that
> I'm running Kernel version 2.6.10 (I know is old but I can't move to a
> newer version due to custom drivers). The second thing is that the link
> between the two SCTP node is a very noisy and some messages are getting
> lost (i.e. the INIT_ACK from the peer in this particular case).
> 
> After analyzing the SCTP code I came out with the following code
> changes:
> 

It does appear to be a genuine bug in lkSCTP, but your solution is
not correct.

The problem is that the original association didn't get the
association id yet in this particular scenario.

Let me take a deeper look at this to see if I can figure our
a better solution.

Thanks
-vlad

Re: [SCTP] Initialization collision problem

[Vlad Yasevich]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

Hi Oscar

Isaula Oscar-QOI000 wrote:
> I ran into a problem where LKSCTP is reporting a SCTM_COMM_UP indication
> to the User application but is giving back a value of zero for the
> assoc_id.
> 
> Attached are the SCTP debugs for the period in question.
> 
> A couple of things that I would like to note about my setup. One is that
> I'm running Kernel version 2.6.10 (I know is old but I can't move to a
> newer version due to custom drivers). The second thing is that the link
> between the two SCTP node is a very noisy and some messages are getting
> lost (i.e. the INIT_ACK from the peer in this particular case).
> 

Can you give this patch a try and let me know if this fixes your issue?

Thanks
-vlad

[-- Attachment #2: oscar_patch.txt --]
[-- Type: text/plain, Size: 7011 bytes --]

diff --git a/include/net/sctp/command.h b/include/net/sctp/command.h
index 4e0e224..7a426d3 100644
--- a/include/net/sctp/command.h
+++ b/include/net/sctp/command.h
@@ -97,6 +97,8 @@ typedef enum {
 	SCTP_CMD_DEL_NON_PRIMARY, /* Removes non-primary peer transports. */
 	SCTP_CMD_T3_RTX_TIMERS_STOP, /* Stops T3-rtx pending timers */
 	SCTP_CMD_FORCE_PRIM_RETRAN,  /* Forces retrans. over primary path. */
+	SCTP_CMD_ASSOC_CHANGE,	 /* generate and send assoc_change event */
+	SCTP_CMD_ADAPTATION_IND, /* generate and send adaptation event */
 	SCTP_CMD_LAST
 } sctp_verb_t;
 
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 3bd04bc..4742fdd 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -1732,6 +1732,7 @@ void sctp_assoc_set_primary(struct sctp_association *,
 int sctp_assoc_set_bind_addr_from_ep(struct sctp_association *, int);
 int sctp_assoc_set_bind_addr_from_cookie(struct sctp_association *,
 					 struct sctp_cookie*, int gfp);
+int sctp_assoc_set_id(struct sctp_association *, int);
 
 int sctp_cmp_addr_exact(const union sctp_addr *ss1,
 			const union sctp_addr *ss2);
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 498a713..09fd31e 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -987,6 +987,13 @@ void sctp_assoc_update(struct sctp_association *asoc,
 			asoc->ssnmap = new->ssnmap;
 			new->ssnmap = NULL;
 		}
+
+		if (!asoc->assoc_id) {
+			/* get a new association id since we don't have one
+			 * yet.
+			 */
+			sctp_assoc_set_id(asoc, GFP_ATOMIC);
+		}
 	}
 }
 
@@ -1222,3 +1229,25 @@ out:
 	sctp_read_unlock(&asoc->base.addr_lock);
 	return found;
 }
+
+/* Set an association id for a given association */
+int sctp_assoc_set_id(struct sctp_association *asoc, int gfp)
+{
+	int assoc_id;
+	int error = 0;
+retry:
+	if (unlikely(!idr_pre_get(&sctp_assocs_id, gfp)))
+		return -ENOMEM;
+
+	spin_lock_bh(&sctp_assocs_id_lock);
+	error = idr_get_new_above(&sctp_assocs_id, (void *)asoc,
+				    1, &assoc_id);
+	spin_unlock_bh(&sctp_assocs_id_lock);
+	if (error == -EAGAIN)
+		goto retry;
+	else if (error)
+		return error;
+
+	asoc->assoc_id = (sctp_assoc_t) assoc_id;
+	return error;
+}
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 1f0676d..98cfbbd 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -1853,7 +1853,6 @@ int sctp_process_init(struct sctp_association *asoc, sctp_cid_t cid,
 	/* Allocate storage for the negotiated streams if it is not a temporary 	 * association.
 	 */
 	if (!asoc->temp) {
-		int assoc_id;
 		int error;
 
 		asoc->ssnmap = sctp_ssnmap_new(asoc->c.sinit_max_instreams,
@@ -1861,19 +1860,9 @@ int sctp_process_init(struct sctp_association *asoc, sctp_cid_t cid,
 		if (!asoc->ssnmap)
 			goto clean_up;
 
-	retry:
-		if (unlikely(!idr_pre_get(&sctp_assocs_id, gfp)))
+		error = sctp_assoc_set_id(asoc, gfp);
+		if (error)
 			goto clean_up;
-		spin_lock_bh(&sctp_assocs_id_lock);
-		error = idr_get_new_above(&sctp_assocs_id, (void *)asoc, 1,
-					  &assoc_id);
-		spin_unlock_bh(&sctp_assocs_id_lock);
-		if (error == -EAGAIN)
-			goto retry;
-		else if (error)
-			goto clean_up;
-
-		asoc->assoc_id = (sctp_assoc_t) assoc_id;
 	}
 
 	/* ADDIP Section 4.1 ASCONF Chunk Procedures
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index c9705de..43155c8 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -786,6 +786,33 @@ static void sctp_cmd_del_non_primary(struct sctp_association *asoc)
 	return;
 }
 
+/* Helper function to generate an association change event */
+static void sctp_cmd_assoc_change(sctp_cmd_seq_t *commands,
+				 struct sctp_association *asoc,
+				 u8 state)
+{
+	struct sctp_ulpevent *ev;
+
+	ev = sctp_ulpevent_make_assoc_change(asoc, 0, state, 0,
+					    asoc->c.sinit_num_ostreams,
+					    asoc->c.sinit_max_instreams,
+					    GFP_ATOMIC);
+	if (ev)
+		sctp_ulpq_tail_event(&asoc->ulpq, ev);
+}
+
+/* Helper function to generate an adaptation indication event */
+static void sctp_cmd_adaptation_ind(sctp_cmd_seq_t *commands,
+				    struct sctp_association *asoc)
+{
+	struct sctp_ulpevent *ev;
+
+	ev = sctp_ulpevent_make_adaptation_indication(asoc, GFP_ATOMIC);
+
+	if (ev)
+		sctp_ulpq_tail_event(&asoc->ulpq, ev);
+}
+
 /* These three macros allow us to pull the debugging code out of the
  * main flow of sctp_do_sm() to keep attention focused on the real
  * functionality there.
@@ -1353,6 +1380,14 @@ int sctp_cmd_interpreter(sctp_event_t event_type, sctp_subtype_t subtype,
 			local_cork = 0;
 			asoc->peer.retran_path = t;
 			break;
+		case SCTP_CMD_ASSOC_CHANGE:
+			sctp_cmd_assoc_change(commands, asoc,
+					      cmd->obj.u8);
+			break;
+		case SCTP_CMD_ADAPTATION_IND:
+			sctp_cmd_adaptation_ind(commands, asoc);
+			break;
+
 		default:
 			printk(KERN_WARNING "Impossible command: %u, %p\n",
 			       cmd->verb, cmd->obj.ptr);
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index 7871faa..99cb9a7 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -1521,7 +1521,6 @@ static sctp_disposition_t sctp_sf_do_dupcook_b(const struct sctp_endpoint *ep,
 					struct sctp_association *new_asoc)
 {
 	sctp_init_chunk_t *peer_init;
-	struct sctp_ulpevent *ev;
 	struct sctp_chunk *repl;
 
 	/* new_asoc is a brand-new association, so these are not yet
@@ -1552,34 +1551,28 @@ static sctp_disposition_t sctp_sf_do_dupcook_b(const struct sctp_endpoint *ep,
 	 * D) IMPLEMENTATION NOTE: An implementation may choose to
 	 * send the Communication Up notification to the SCTP user
 	 * upon reception of a valid COOKIE ECHO chunk.
-	 */
-	ev = sctp_ulpevent_make_assoc_change(asoc, 0, SCTP_COMM_UP, 0,
-					     new_asoc->c.sinit_num_ostreams,
-					     new_asoc->c.sinit_max_instreams,
-					     GFP_ATOMIC);
-	if (!ev)
-		goto nomem_ev;
-
-	sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP, SCTP_ULPEVENT(ev));
+	 *
+	 * Sadly, this needs to be implemented as a side-effect, because
+	 * we are not guaranteed to have set the association id of the real
+	 * association and so these notifications need to be delayed until
+	 * the association id is allocated.
+  	 */
+  
+	sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_CHANGE, SCTP_U8(SCTP_COMM_UP));
 
 	/* Sockets API Draft Section 5.3.1.6
 	 * When a peer sends a Adaption Layer Indication parameter , SCTP
 	 * delivers this notification to inform the application that of the
 	 * peers requested adaption layer.
-	 */
-	if (asoc->peer.adaption_ind) {
-		ev = sctp_ulpevent_make_adaption_indication(asoc, GFP_ATOMIC);
-		if (!ev)
-			goto nomem_ev;
-
-		sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
-				SCTP_ULPEVENT(ev));
-	}
+	 *
+	 * This also needs to be done as a side effect for the same reason as
+	 * above.
+  	 */
+	if (asoc->peer.adaptation_ind)
+		sctp_add_cmd_sf(commands, SCTP_CMD_ADAPTATION_IND, SCTP_NULL());
 
 	return SCTP_DISPOSITION_CONSUME;
 
-nomem_ev:
-	sctp_chunk_free(repl);
 nomem:
 	return SCTP_DISPOSITION_NOMEM;
 }

RE: [SCTP] Initialization collision problem

[Isaula Oscar-QOI000]

Vlad,

I finally got test results for the changes you suggested. The original
issue is fixed and I have not detected any side effects.

Thanks,
Oscar 

-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Vlad Yasevich
Sent: Wednesday, April 11, 2007 9:45 AM
To: Isaula Oscar-QOI000
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [SCTP] Initialization collision problem

Hi Oscar

Isaula Oscar-QOI000 wrote:
> I ran into a problem where LKSCTP is reporting a SCTM_COMM_UP 
> indication to the User application but is giving back a value of zero 
> for the assoc_id.
> 
> Attached are the SCTP debugs for the period in question.
> 
> A couple of things that I would like to note about my setup. One is 
> that I'm running Kernel version 2.6.10 (I know is old but I can't move

> to a newer version due to custom drivers). The second thing is that 
> the link between the two SCTP node is a very noisy and some messages 
> are getting lost (i.e. the INIT_ACK from the peer in this particular
case).
> 

Can you give this patch a try and let me know if this fixes your issue?

Thanks
-vlad

Re: [SCTP] Initialization collision problem

[Vlad Yasevich]

Isaula Oscar-QOI000 wrote:
> Vlad,
> 
> I finally got test results for the changes you suggested. The original
> issue is fixed and I have not detected any side effects.

Thanks.

-vlad

> 
> Thanks,
> Oscar 
> 
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Vlad Yasevich
> Sent: Wednesday, April 11, 2007 9:45 AM
> To: Isaula Oscar-QOI000
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [SCTP] Initialization collision problem
> 
> Hi Oscar
> 
> Isaula Oscar-QOI000 wrote:
>> I ran into a problem where LKSCTP is reporting a SCTM_COMM_UP 
>> indication to the User application but is giving back a value of zero 
>> for the assoc_id.
>>
>> Attached are the SCTP debugs for the period in question.
>>
>> A couple of things that I would like to note about my setup. One is 
>> that I'm running Kernel version 2.6.10 (I know is old but I can't move
> 
>> to a newer version due to custom drivers). The second thing is that 
>> the link between the two SCTP node is a very noisy and some messages 
>> are getting lost (i.e. the INIT_ACK from the peer in this particular
> case).
> 
> Can you give this patch a try and let me know if this fixes your issue?
> 
> Thanks
> -vlad
> 

RE: [SCTP] Initialization collision problem

[Isaula Oscar-QOI000]

Vlad,

Will these changes make it into the next Kernel release? If so which one
will it be?

Thanks,
Oscar 

-----Original Message-----
From: Vlad Yasevich [mailto:vladislav.yasevich@hp.com] 
Sent: Tuesday, May 01, 2007 3:19 PM
To: Isaula Oscar-QOI000
Cc: netdev@vger.kernel.org
Subject: Re: [SCTP] Initialization collision problem

Isaula Oscar-QOI000 wrote:
> Vlad,
> 
> I finally got test results for the changes you suggested. The original

> issue is fixed and I have not detected any side effects.

Thanks.

-vlad

> 
> Thanks,
> Oscar
> 
> -----Original Message-----
> From: netdev-owner@vger.kernel.org 
> [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Vlad Yasevich
> Sent: Wednesday, April 11, 2007 9:45 AM
> To: Isaula Oscar-QOI000
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [SCTP] Initialization collision problem
> 
> Hi Oscar
> 
> Isaula Oscar-QOI000 wrote:
>> I ran into a problem where LKSCTP is reporting a SCTM_COMM_UP 
>> indication to the User application but is giving back a value of zero

>> for the assoc_id.
>>
>> Attached are the SCTP debugs for the period in question.
>>
>> A couple of things that I would like to note about my setup. One is 
>> that I'm running Kernel version 2.6.10 (I know is old but I can't 
>> move
> 
>> to a newer version due to custom drivers). The second thing is that 
>> the link between the two SCTP node is a very noisy and some messages 
>> are getting lost (i.e. the INIT_ACK from the peer in this particular
> case).
> 
> Can you give this patch a try and let me know if this fixes your
issue?
> 
> Thanks
> -vlad
>