No other choice. Without this, peer that requested DSS checksum will reset
the connection as soon as DSS options without checksums arrive.
squashto: mptcp: Handle MPTCP TCP options
Cc: Peter Krystad <peter.krystad(a)linux.intel.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
net/mptcp/options.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index 9f892478d336..deee4394c4c5 100644
@@ -37,6 +37,22 @@ void mptcp_parse_option(const unsigned char *ptr, int opsize,
(mp_opt->flags & MPTCP_CAP_EXTENSIBILITY))
+ /* RFC 6824, Section 3.1:
+ * "For the Checksum Required bit (labeled "A"), if either
+ * host requires the use of checksums, checksums MUST be used.
+ * In other words, the only way for checksums not to be used
+ * is if both hosts in their SYNs set A=0."
+ * Section 3.3.0:
+ * "If a checksum is not present when its use has been
+ * negotiated, the receiver MUST close the subflow with a RST as it is
+ * considered broken."
+ * We don't implement DSS checksum - fall back to TCP.
+ if (mp_opt->flags & MPTCP_CAP_CHECKSUM_REQD)
mp_opt->mp_capable = 1;
mp_opt->sndr_key = get_unaligned_be64(ptr);
ptr += 8;
Just FYI, I've asked Eric Dumazet on how/where to add MIB stats for
I don't think its high-prio to have them right now but I think its
important to add MPTCP stats at some point.
----- Forwarded message from Florian Westphal <fw(a)strlen.de> -----
The out-of-tree multipath TCP stack adds a few MIB counters to track
(and debug) MTPCP behaviour. Examples:
and so on.
I think that such MIB counters would be good to have in the 'upstreaming'
attempt as well.
The out-of-tree code keeps them separate from the tcp mib counters and also
exposes them in a different /proc file (/proc/net/mptcp_net/snmp).
Would you be ok with mptcp-upstreaming adding its MIB counters to the
existing TCP MIB instead?
This would make 'nstat' and other tools pick them up automatically.
It would also help TCP highlevel debugging to see if MPTCP is involved
in any way.
Let me know -- I can go with a separate MIB, its no problem, I just want
to avoid going down the wrong path.
----- End forwarded message -----
Note this is still early draft, only lightly tested. It builds and somtimes
it passes the selftests
In addition to the first iteration now:
- implement actual retransmission infrastructure and trigger it when MPTCP
timer expires (patches 7,8)
- fixes several bugs in many patches - but others are still there
- updates the MPTCP unacked sequence number (patches 1-3) on sendmsg()
- also try to cope with 32 bit sequence number
- queue data (page frags) in MPTCP retransmission queue
- cleanup acked data from retransmission queue and schedule a timeout to
update MPTCP unacked sequence number (patch 5)
- IIRC, the RFC mandate to always retransmit even on the failing subflow (?!?)
why? Should we preserve the original subflow seq number, so that
retransmission there will get the same mapping as the original packet?
Paolo Abeni (8):
mptcp: move before/after64 into the header file
mptcp: update per subflow unacked sequence on pkt reception
mptcp: update msk unacked sequence in sendmsg()
mptcp: queue data for mptcp level retransmission
mptcp: use retransmission timer to update msk una
mptcp: implement memory accounting for mptcp rtx queue
mptcp: rework mptcp_sendmsg_frag to accept optional dfrag
mptcp: implement and use MPTCP-level retransmission
net/mptcp/options.c | 31 +++-
net/mptcp/protocol.c | 405 +++++++++++++++++++++++++++++++++++++++----
net/mptcp/protocol.h | 41 +++++
3 files changed, 437 insertions(+), 40 deletions(-)