netdev - RE: [PATCH net-next v4 0/7] bonding: Extend arp_ip_target format to allow for a list of vlan tags.

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:
 <MW3PR15MB3913268E49B5D040CFF75107FA2CA@MW3PR15MB3913.namprd15.prod.outlook.com>
Date: Thu, 7 Aug 2025 16:24:35 +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>
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: Wednesday, August 6, 2025 9:38 PM
To: David Wilder
Cc: netdev@...r.kernel.org; jv@...sburgh.net; pradeeps@...ux.vnet.ibm.com; Pradeep Satyanarayana; i.maximets@....org; Adrian Moreno Zapata
Subject: [EXTERNAL] Re: [PATCH net-next v4 0/7] bonding: Extend arp_ip_target format to allow for a list of vlan tags.

Hi Hangbin

> Hi David,
> On Tue, Jul 01, 2025 at 07:13:06AM +0000, Hangbin Liu wrote:
> > 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?

> I looked into this recently, and you are right — ip6_route_output() returns
> an error dst. The root cause is that we cannot get the destination IPv6
> address through the bond interface, because the source IPv6 address is
> configured on other interfaces, the VLAN sub-interface.
>
> This is a key difference between IPv6 and IPv4:
> In IPv4, it's possible to get a destination route via the bond even when the
> source IP is configured on a different interface. But in IPv6, the routing
> mechanism is stricter in requiring the source address to be valid on the
> outgoing interface.
>
> I'm not sure how to fix this yet, as it's fundamentally tied to how IPv6
> routing behaves.

I am thinking that we don't need to do a route lookup as if we are sending
from the bonding interface.  We only need to find the interface we should
send the packet through.  As if we ran "ip route get <dest addr>".

David Wilder