TCP: sack_unchanged_irregular handling wrong
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
rohc | Status tracked in Rohc-main | |||||
Rohc-1.7.x |
Won't Fix
|
Medium
|
Didier Barvaux | |||
Rohc-main |
Fix Released
|
Medium
|
Didier Barvaux |
Bug Description
Hello,
in case of no sack data are transmitted in the irregular chain,
all SACK data are omitted on rebuild.
The test case is ipv4_tcp_
The first and the second packet are equal, therefore no
SACK data needed to transmitted again.
The RoHC pakcet are:
[DEBUG] [rohc_traces_
[DEBUG] [rohc_traces_
[DEBUG] [rohc_traces_
[DEBUG] [rohc_traces_
[DEBUG] [rohc_traces_
[DEBUG] [rohc_traces_
[DEBUG] [rohc_traces_
The discriminator while calling tcp_sack.c d_tcp_sack_parse() is 0.
No data are transmitted, but opt_sack->blocks_nr is overwritten with 0.
While rebuilding in d_tcp_build_sack() no data are rebuild.
I suggest the patch:
diff --git a/src/decomp/
index ade42df..e1b8ea3 100644
--- a/src/decomp/
+++ b/src/decomp/
@@ -107,8 +107,11 @@ int d_tcp_sack_
}
- opt_sack->blocks_nr = discriminator;
-
+ if (discriminator > 0)
+ {
+ opt_sack->blocks_nr = discriminator;
+ }
+
return (data_len - remain_data_len);
error:
to avoid the error in case of sack_unchanged_
Best,
Klaus Warnke
Klaus,
You're right, once more. The case with unchanged SACK option is not handled correctly. Thank you for the report!
However, I'm afraid that your fix proposal is not reliable. If discriminator is 0, you doesn't record anything into the struct d_tcp_opt_ctxt, so you keep the old values. By chance the old values seem to be the values of the previous SACK option, so it gives the good result. I would prefer to record an indication that the SACK option shall be retrieved from context, and then during the decoding phase retrieve the values from context. Some other options are implemented this way when static values are not transmitted. I'll implement something this way asap.
Regards,
Didier