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-next>] [day] [month] [year] [list]
Message-ID: <de8d8ca4-4ead-0cef-1315-8764d93503c1@redhat.com>
Date:   Tue, 17 May 2022 17:17:19 -0400
From:   Jonathan Toppins <jtoppins@...hat.com>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     Jay Vosburgh <j.vosburgh@...il.com>,
        Veaceslav Falico <vfalico@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
Subject: [question] bonding: should assert dormant for active protocols like
 LACP?

So running the following script:

--%<-----
  ip link add name link-bond0 type veth peer name link-end0
  ip link add bond0 type bond mode 4 miimon 100
  ip link set link-bond0 master bond0 down
  ip netns add n1
  ip link set link-end0 netns n1 up
  ip link set bond0 up
  cat /sys/class/net/bond0/bonding/ad_partner_mac
  cat /sys/class/net/bond0/operstate
--%<-----

The bond reports its operstate to be "up" even though the bond will 
never be able to establish an LACP partner. Should bonding for active 
protocols, LACP, assert dormant[0] until the protocol has established 
and frames actually are passed?

Having a predictable operstate where up actually means frames will 
attempt to be delivered would make management applications, f.e. Network 
Manager, easier to write. I have developers asking me what detailed 
states for LACP should they be looking for to determine when an LACP 
bond is "up". This seems like an incorrect implementation of operstate 
and RFC2863 3.1.12.

Does anyone see why this would be a bad idea?

-Jon

[0] Documentation/networking/operstates.rst

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ