From patchwork Fri Nov 29 14:44:05 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Davide Caratti X-Patchwork-Id: 1202505 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.01.org (client-ip=198.145.21.10; helo=ml01.01.org; envelope-from=mptcp-bounces@lists.01.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.b="FJJR0xpc"; dkim-atps=neutral Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 47Pcj02hk8z9s7T for ; Sat, 30 Nov 2019 01:44:18 +1100 (AEDT) Received: from ml01.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 723FB1011350E; Fri, 29 Nov 2019 06:47:38 -0800 (PST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=207.211.31.81; helo=us-smtp-delivery-1.mimecast.com; envelope-from=dcaratti@redhat.com; receiver= Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8D8F1100EA602 for ; Fri, 29 Nov 2019 06:47:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575038651; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BGio9JhjK0gh5NiRF6a+SE5jK/svk0auf8QIPbghLx8=; b=FJJR0xpclP+delZjtQLMAuyvKUImgNZGDhW30TkTgQUn3Jsu/dqj1v6FnI0MDhy4RBHNt8 m4c5UEvyuLQfrxYywuQHCwD4vM8OG2KxNDqMje90IHtD2TFySYjFTAGy3+Rvho1q66J6R2 rUVsIG1C5ignYZc0VXjD3Afm3IUggHI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-351-TjbMjkJ3PF2SOgPHjmnhWw-1; Fri, 29 Nov 2019 09:44:09 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 89E7D800C76; Fri, 29 Nov 2019 14:44:07 +0000 (UTC) Received: from ovpn-204-242.brq.redhat.com (ovpn-204-242.brq.redhat.com [10.40.204.242]) by smtp.corp.redhat.com (Postfix) with ESMTP id 71095600CC; Fri, 29 Nov 2019 14:44:06 +0000 (UTC) Message-ID: From: Davide Caratti To: Matthieu Baerts In-Reply-To: <8b6fd3ba-c34d-d863-e958-1390c991b360@tessares.net> References: <20191107152827.54549-1-cpaasch@apple.com> <20191107152827.54549-2-cpaasch@apple.com> <965954023c7a67bfd8e7f42bba7c19b512b8241c.camel@redhat.com> <8b6fd3ba-c34d-d863-e958-1390c991b360@tessares.net> Organization: red hat Date: Fri, 29 Nov 2019 15:44:05 +0100 MIME-Version: 1.0 User-Agent: Evolution 3.34.1 (3.34.1-1.fc31) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: TjbMjkJ3PF2SOgPHjmnhWw-1 X-Mimecast-Spam-Score: 0 Message-ID-Hash: FKCA4KQANA2CDA6UUQUO3HLSXEVROV2P X-Message-ID-Hash: FKCA4KQANA2CDA6UUQUO3HLSXEVROV2P X-MailFrom: dcaratti@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: mptcp@lists.01.org X-Mailman-Version: 3.1.1 Precedence: list Subject: [MPTCP] Re: [PATCH 1/2] mptcp: parse and emit MP_CAPABLE option according to v1 spec. List-Id: Discussions regarding MPTCP upstreaming Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: hello Matthieu, thanks a lot for looking at this! On Fri, 2019-11-29 at 14:33 +0100, Matthieu Baerts wrote: > Hi Davide, > > > > https://github.com/dcaratti/packetdrill/issues/1#issuecomment-559569544 > > The new version of packetdrill is already helping us finding issues \o/ yay! :) > > is it possible to fix size of the syn/ack generated by v0 version of the > > protocol as a separate patch? Otherwise I will need to add a special > > handling for SYN/ACK packets generated by v0 net-next kernels packets. > > > > (the code I tried is quite trivial, and it passes the smoke-test in > > tools/testing/selftests) > > Thank you for the patch! It looks good to me. > I think it would be good to apply it before applying v1 patch. > > May you send a "proper patch"? If there is no objection (and an > additional review?), I can apply it. I'm doubtful of what should we do with the first hunk, i.e. /* MPTCPOPT_MP_JOIN here the kernel stores in mp_opt->rcvr_key the value received on the "longer" mp_capable option (that is, the 3rd packet in the 3-way handshake). I don't really get what the server should do with the echoed key received by the client, and a grep over the code didn't help: $ grep -r rcvr_key net/* include/* net/mptcp/options.c: opts->rcvr_key = subflow->remote_key; net/mptcp/options.c: opts->rcvr_key = subflow_req->remote_key; net/mptcp/options.c: put_unaligned_be64(opts->rcvr_key, ptr); include/linux/tcp.h: u64 rcvr_key; include/net/mptcp.h: u64 rcvr_key; I take as a friday activity (when packetdrill will be in a decent shape... so, not not this friday :) ) to understand what happens to a mptcp-net-next server when the client echoes back a wrong key. To be as much conservative as possible (and preserve the debug printout), we could just replace the above hunk with the following one: --- >8 --- --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -57,7 +57,7 @@ void mptcp_parse_option(const unsigned char *ptr, int opsize, mp_opt->sndr_key = get_unaligned_be64(ptr); ptr += 8; - if (opsize == TCPOLEN_MPTCP_MPC_SYNACK) { + if (opsize == TCPOLEN_MPTCP_MPC_ACK) { mp_opt->rcvr_key = get_unaligned_be64(ptr); ptr += 8; pr_debug("MP_CAPABLE flags=%x, sndr=%llu, rcvr=%llu", --- >8 --- that will also create less troubles to Christian when he rebases his v1 mp_capable patch on top of this. WDYT? --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -57,16 +57,8 @@ void mptcp_parse_option(const unsigned char *ptr, int opsize, mp_opt->sndr_key = get_unaligned_be64(ptr); ptr += 8; - if (opsize == TCPOLEN_MPTCP_MPC_SYNACK) { - mp_opt->rcvr_key = get_unaligned_be64(ptr); - ptr += 8; - pr_debug("MP_CAPABLE flags=%x, sndr=%llu, rcvr=%llu", - mp_opt->flags, mp_opt->sndr_key, - mp_opt->rcvr_key); - } else { - pr_debug("MP_CAPABLE flags=%x, sndr=%llu", - mp_opt->flags, mp_opt->sndr_key); - } + pr_debug("MP_CAPABLE flags=%x, sndr=%llu", + mp_opt->flags, mp_opt->sndr_key); break;