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]
Message-ID:
 <MW3PR15MB391317D5FD3E0DCE1E592EE0FA46A@MW3PR15MB3913.namprd15.prod.outlook.com>
Date: Mon, 30 Jun 2025 16:19:22 +0000
From: David Wilder <wilder@...ibm.com>
To: Hangbin Liu <liuhangbin@...il.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "jv@...sburgh.net"
	<jv@...sburgh.net>,
        "pradeeps@...ux.vnet.ibm.com"
	<pradeeps@...ux.vnet.ibm.com>,
        Pradeep Satyanarayana <pradeep@...ibm.com>,
        "i.maximets@....org" <i.maximets@....org>,
        Adrian Moreno Zapata
	<amorenoz@...hat.com>,
        Hangbin Liu <haliu@...hat.com>
Subject: RE: [PATCH net-next v4 0/7] bonding: Extend arp_ip_target format to allow
 for a list of vlan tags.




________________________________________
From: Hangbin Liu <liuhangbin@...il.com>
Sent: Monday, June 30, 2025 3:18 AM
To: David Wilder
Cc: netdev@...r.kernel.org; jv@...sburgh.net; pradeeps@...ux.vnet.ibm.com; Pradeep Satyanarayana; i.maximets@....org; Adrian Moreno Zapata; Hangbin Liu
Subject: [EXTERNAL] Re: [PATCH net-next v4 0/7] bonding: Extend arp_ip_target format to allow for a list of vlan tags.

> On Fri, Jun 27, 2025 at 01:17:13PM -0700, David Wilder wrote:
> I have run into issues with the ns_ip6_target feature.  I am unable to get
> the existing code to function with vlans. Therefor I am unable to support
> A this change for ns_ip6_target.

> Any reason why this is incompatible with ns_ip6_target?

Hi Hangbin

I am unable to get the existing ns_ip6_target code to function when the target
is in a vlan. If the existing code is not working with vlans it makes no
sense to specify the vlan tags.

This is what I think is happening:

In ns_send_all() we have this bit of code:

dst = ip6_route_output(dev_net(bond->dev), NULL, &fl6);
if (dst->error) {
        dst_release(dst);
        /* there's no route to target - try to send arp
         * probe to generate any traffic (arp_validate=0)
         */
        if (bond->params.arp_validate)
               bond_ns_send(slave, &targets[i], &in6addr_any, tags);
               <.......>
               continue;
}

ip6_route_output() is returning an error as there is no neighbor entry for
the target. A ns is then sent with no vlan header. I found that the
multicast ns (with no vlan header) is not passed to the vlan siblings
with the target address so no reply is sent.

The ipv4 code is simmiler but the arp is sent as a brodcast. The broadcast arp
will be propagated to the vlan sibling (in the linux vlan code).

This could be a testing issue,  I am unsure.  Can you help with
a test case with the target in a vlan?

Thanks
  David Wilder

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ