[PATCH 3/4] dccp: Don't Reset On Confirm for Old NN Feature Values

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


The Current DCCP code resets the connection when it encounters a Confirm
for an NN feature with a value that doesn't match the most recent Change
sent. However, this causes unneeded resets if an NN option changes twice
within two RTTs. Further, this would break on the multiple Change
options for a feature in one packet example in RFC4340 6.6.1.

This patch modifies the code to simply ignore such a Confirm Option.

--- 
Signed-off-by: Samuel Jero
diff --git a/net/dccp/feat.c b/net/dccp/feat.c
index 6f2bc96..e5c1bad 100644
--- a/net/dccp/feat.c
+++ b/net/dccp/feat.c
@@ -1347,10 +1347,8 @@ static u8 dccp_feat_handle_nn_established(struct sock *sk, u8 mandatory, u8 opt,
 			return 0;
 
 		fval.nn = dccp_decode_value_var(val, len);
-		if (fval.nn != entry->val.nn) {
-			DCCP_WARN("Bogus Confirm for non-existing value\n");
-			goto fast_path_failed;
-		}
+		if (fval.nn != entry->val.nn)
+			return 0;
 
 		/* It has been confirmed - so remove the entry */
 		dccp_feat_list_pop(entry);

Attachment: signature.asc
Description: This is a digitally signed message part


[Linux Kernel]     [IETF DCCP]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Linux Resources]

Powered by Linux