netdev - Re: HSR/PRP sequence counter issue with Cisco Redbox

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 28 Jan 2021 17:11:38 -0600
From:   George McCollister <george.mccollister@...il.com>
To:     "Wenzel, Marco" <Marco.Wenzel@...berle.de>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: HSR/PRP sequence counter issue with Cisco Redbox

On Wed, Jan 27, 2021 at 6:32 AM Wenzel, Marco <Marco.Wenzel@...berle.de> wrote:
>
> 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 ():
>
> 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;
>
>
> 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?

This isn't the correct way to solve the problem. IEC 62439-3 defines
EntryForgetTime as "Time after which an entry is removed from the
duplicate table" with a value of 400ms and states devices should
usually be configured to keep entries in the table for a much shorter
time. hsr_framereg.c needs to be reworked to handle this according to
the specification.

>
> Thanks
> Marco Wenzel

Regards,
George McCollister