From patchwork Wed Jan 27 12:15:34 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Wenzel, Marco" X-Patchwork-Id: 12049947 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CB3AC433E0 for ; Wed, 27 Jan 2021 12:29:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0A61620795 for ; Wed, 27 Jan 2021 12:29:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237933AbhA0M2b convert rfc822-to-8bit (ORCPT ); Wed, 27 Jan 2021 07:28:31 -0500 Received: from mail.a-eberle.de ([213.95.140.213]:54296 "EHLO mail.a-eberle.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234451AbhA0MZw (ORCPT ); Wed, 27 Jan 2021 07:25:52 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.a-eberle.de (Postfix) with ESMTP id AEEA93806DF for ; Wed, 27 Jan 2021 13:15:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aeberle-mx.softwerk.noris.de Received: from mail.a-eberle.de ([127.0.0.1]) by localhost (ebl-mx-02.a-eberle.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3z3ekvEowCy for ; Wed, 27 Jan 2021 13:15:39 +0100 (CET) Received: from gateway.a-eberle.de (unknown [178.15.155.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "sg310.eberle.local", Issuer "A. Eberle GmbH & Co. KG WebAdmin CA" (not verified)) (Authenticated sender: postmaster@a-eberle.de) by mail.a-eberle.de (Postfix) with ESMTPSA for ; Wed, 27 Jan 2021 13:15:39 +0100 (CET) Received: from exch-svr2013.eberle.local ([192.168.1.9]:60091 helo=webmail.a-eberle.de) by gateway.a-eberle.de with esmtps (TLSv1.2:AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1l4jjT-00043E-0u for netdev@vger.kernel.org; Wed, 27 Jan 2021 13:15:35 +0100 Received: from EXCH-SVR2013.eberle.local (192.168.1.9) by EXCH-SVR2013.eberle.local (192.168.1.9) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 27 Jan 2021 13:15:35 +0100 Received: from EXCH-SVR2013.eberle.local ([::1]) by EXCH-SVR2013.eberle.local ([::1]) with mapi id 15.00.1497.006; Wed, 27 Jan 2021 13:15:35 +0100 From: "Wenzel, Marco" To: "netdev@vger.kernel.org" Subject: HSR/PRP sequence counter issue with Cisco Redbox Thread-Topic: HSR/PRP sequence counter issue with Cisco Redbox Thread-Index: Adb0oMB5N/nh+lgRSvKGIOcbXjKnGA== Date: Wed, 27 Jan 2021 12:15:34 +0000 Message-ID: <69ec2fd1a9a048e8b3305a4bc36aad01@EXCH-SVR2013.eberle.local> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.242.2.55] x-kse-serverinfo: EXCH-SVR2013.eberle.local, 9 x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean, bases: 27.01.2021 08:13:00 x-kse-attachment-filter-triggered-rules: Clean x-kse-attachment-filter-triggered-filters: Clean x-kse-bulkmessagesfiltering-scan-result: protection disabled MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi, we have figured out an issue with the current PRP driver when trying to communicate with Cisco IE 2000 industrial Ethernet switches in Redbox mode. The Cisco always resets the HSR/PRP sequence counter to "1" at low traffic (<= 1 frame in 400 ms). It can be reproduced by a simple ICMP echo request with 1 s interval between a Linux box running with PRP and a VDAN behind the Cisco Redbox. The Linux box then always receives frames with sequence counter "1" and drops them. The behavior is not configurable at the Cisco Redbox. I fixed it by ignoring sequence counters with value "1" at the sequence counter check in hsr_register_frame_out (): Do you think this could be a solution? Should this patch be officially applied in order to avoid other users running into these communication issues? Thanks Marco Wenzel diff --git a/net/hsr/hsr_framereg.c b/net/hsr/hsr_framereg.c index 5c97de459905..630c238e81f0 100644 --- a/net/hsr/hsr_framereg.c +++ b/net/hsr/hsr_framereg.c @@ -411,7 +411,7 @@ void hsr_register_frame_in(struct hsr_node *node, struct hsr_port *port, int hsr_register_frame_out(struct hsr_port *port, struct hsr_node *node, u16 sequence_nr) { - if (seq_nr_before_or_eq(sequence_nr, node->seq_out[port->type])) + if (seq_nr_before_or_eq(sequence_nr, node->seq_out[port->type]) && (sequence_nr != 1)) return 1; node->seq_out[port->type] = sequence_nr;