Add a selftest to verify bonding behavior when `lacp_active` is set to `off`.
The test checks the following:
- The passive LACP bond should not send LACPDUs before receiving a partner's
LACPDU.
- The transmitted LACPDUs must not include the active flag.
- After transitioning to EXPIRE
This ensures that in passive mode, the bond starts sending periodic LACPDUs
after receiving one from the partner, and avoids flapping due to inactivity.
Fixes: 3a755cd8b7c6 ("bonding: add new option lacp_active")
Signed-off-by: Hangbin Liu
---
drivers/net/bonding/bond_3ad.c | 42 +
The port's actor_oper_port_state activity flag should be updated immediately
after changing the lacp_active option to reflect the current mode correctly.
Fixes: 3a755cd8b7c6 ("bonding: add new option lacp_active")
Signed-off-by: Hangbin Liu
---
drivers/net/bonding/bond
This patch fixes unstable LACP negotiation when bonding is configured in
passive mode (`lacp_active=off`).
Previously, the actor would stop sending LACPDUs after initial negotiation
succeeded, leading to the partner timing out and restarting the negotiation
cycle. This resulted in continuous LACP
On Fri, Jul 25, 2025 at 10:27:48AM +0200, Petr Machata wrote:
>
> Hangbin Liu writes:
>
> > On Thu, Jul 24, 2025 at 04:06:03AM +, Hangbin Liu wrote:
> >> On Tue, Jul 15, 2025 at 11:37:54AM +0200, Paolo Abeni wrote:
> >> > > diff --git
> >> &
Hangbin Liu writes:
> On Thu, Jul 24, 2025 at 04:06:03AM +, Hangbin Liu wrote:
>> On Tue, Jul 15, 2025 at 11:37:54AM +0200, Paolo Abeni wrote:
>> > > diff --git
>> > > a/tools/testing/selftests/drivers/net/bonding/bond_passive_lacp.sh
>> > >
On Thu, Jul 24, 2025 at 11:57:53AM +0200, Jay Vosburgh wrote:
> FWIW, I usually reference the older standards 2008 or 2014, as
> the 2020 edition changes a lot of things and bonding isn't necessarily
> conformant to those changes (e.g., many of the state machines are
> diff
passive mode, the actor will not send LACPDU before receiving any LACPDU
>from the partner.
>2. Once it receives the partner’s LACPDU, it will start sending periodic
>LACPDUs as expected.
>
>Do you agree with making these changes? If so, I can post a patch for your
>review.
Yes, please
On Thu, Jul 24, 2025 at 04:06:03AM +, Hangbin Liu wrote:
> On Tue, Jul 15, 2025 at 11:37:54AM +0200, Paolo Abeni wrote:
> > > diff --git
> > > a/tools/testing/selftests/drivers/net/bonding/bond_passive_lacp.sh
> > > b/tools/testing/selftests/drivers/net/bonding/
On Tue, Jul 15, 2025 at 11:37:54AM +0200, Paolo Abeni wrote:
> > diff --git
> > a/tools/testing/selftests/drivers/net/bonding/bond_passive_lacp.sh
> > b/tools/testing/selftests/drivers/net/bonding/bond_passive_lacp.sh
> > new file mode 100755
> > index 0
On Tue, Jul 15, 2025 at 09:19:49PM -0700, Jay Vosburgh wrote:
> Presuming that I'm correct that we're not implementing 6.4.1 d),
> above, correctly, then I don't think this is a proper fix, as it kind of
> band-aids over the problem a bit.
>
> Looking at the code, I suspect the problem
Hangbin Liu wrote:
>On Tue, Jul 15, 2025 at 09:19:49PM -0700, Jay Vosburgh wrote:
>> Hangbin Liu wrote:
>>
>> >When lacp_active is set to off, the bond operates in passive mode, meaning
>> >it
>> >will only "speak when spoken to." However, the current kernel implementation
>> >only sends an LA
On Tue, Jul 15, 2025 at 11:37:54AM +0200, Paolo Abeni wrote:
> On 7/9/25 11:03 AM, Hangbin Liu wrote:
> > Add a selftest to verify bonding behavior when lacp_active is set to off.
> >
> > Signed-off-by: Hangbin Liu
> > ---
> > .../drivers/net/b
On Tue, Jul 15, 2025 at 09:19:49PM -0700, Jay Vosburgh wrote:
> Hangbin Liu wrote:
>
> >When lacp_active is set to off, the bond operates in passive mode, meaning it
> >will only "speak when spoken to." However, the current kernel implementation
> >only sends an LACPDU in response when the partne
of bond_params->lacp_active here, and,
b) The lacp_active option setting controls whether LACP_ACTIVITY
is set in port->actor_oper_port_state.
Thoughts?
-J
>Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>Signed-off-by: Hangbin Liu
>---
> driv
On 7/9/25 11:03 AM, Hangbin Liu wrote:
> Add a selftest to verify bonding behavior when lacp_active is set to off.
>
> Signed-off-by: Hangbin Liu
> ---
> .../drivers/net/bonding/bond_passive_lacp.sh | 21 +
> .../drivers/net/bonding/bond_topo_lacp.sh | 77
Add a selftest to verify bonding behavior when lacp_active is set to off.
Signed-off-by: Hangbin Liu
---
.../drivers/net/bonding/bond_passive_lacp.sh | 21 +
.../drivers/net/bonding/bond_topo_lacp.sh | 77 +++
2 files changed, 98 insertions(+)
create mode 100755
tools
econds due to the actor's lacp_rate=slow. By the time
the actor replies, the partner has already timed out and sent an "expired"
LACPDU.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Hangbin Liu
---
drivers/net/bonding/bond_3ad.c | 6 ++
1 file changed, 6 insertions
This patchset fixes an issue where bonding fails to establish a stable LACP
negotiation when operating in passive mode (lacp_active=off).
In passive mode, the current implementation only replies when the partner's
state changes, which results in LACP timeout and unstable aggregator form
__xfrm_state_delete
> > - bond_ipsec_del_sa()
> > - .xdo_dev_state_delete()
> > - bond_ipsec_free_sa()
> > - .xdo_dev_state_free()
>
On Tue, Mar 11, 2025 at 09:08:49PM +, Cosmin Ratiu wrote:
> On Fri, 2025-03-07 at 09:03 -0800, Jakub Kicinski wrote:
> > On Fri, 7 Mar 2025 09:42:49 +0200 Nikolay Aleksandrov wrote:
> > > TBH, keeping buggy code with a comment doesn't sound good to me.
> > > I'd rather remove this
> > > support
On Fri, 2025-03-07 at 09:03 -0800, Jakub Kicinski wrote:
> On Fri, 7 Mar 2025 09:42:49 +0200 Nikolay Aleksandrov wrote:
> > TBH, keeping buggy code with a comment doesn't sound good to me.
> > I'd rather remove this
> > support than tell people "good luck, it might crash". It's better
> > to be saf
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni :
On Thu, 6 Mar 2025 02:39:21 + you wrote:
> The mac address on backup slave should be convert from Solicited-Node
> Multicast address, not from bonding unicast target address.
>
> v4: no change, just repost
On Thu, Mar 06, 2025 at 02:39:23AM +, Hangbin Liu wrote:
> The correct mac address for NS target 2001:db8::254 is 33:33:ff:00:02:54,
> not 33:33:00:00:02:54. The same with client maddress.
>
> Fixes: 86fb6173d11e ("selftests: bonding: add ns multicast group testing")
&g
to the slave. However, the target in bonding is a unicast address, which
> we cannot use directly. Instead, we should first convert it to a
> Solicited-Node Multicast Address and then derive the corresponding MAC
> address.
>
> Fix the incorrect MAC address setting on bo
On Fri, Mar 07, 2025 at 09:03:32AM -0800, Jakub Kicinski wrote:
> On Fri, 7 Mar 2025 09:42:49 +0200 Nikolay Aleksandrov wrote:
> > TBH, keeping buggy code with a comment doesn't sound good to me. I'd rather
> > remove this
> > support than tell people "good luck, it might crash". It's better to be
On Sat, Mar 08, 2025 at 08:54:51AM +, Simon Horman wrote:
> On Fri, Mar 07, 2025 at 03:19:01AM +, Hangbin Liu wrote:
>
> ...
>
> > @@ -616,9 +615,22 @@ static void bond_ipsec_del_sa_all(struct bonding *bond)
> > return;
> >
> &
On Fri, Mar 07, 2025 at 03:19:01AM +, Hangbin Liu wrote:
...
> @@ -616,9 +615,22 @@ static void bond_ipsec_del_sa_all(struct bonding *bond)
> return;
>
> mutex_lock(&bond->ipsec_lock);
> - list_for_each_entry(ipsec, &bond->ipsec_lis
On Fri, 7 Mar 2025 09:42:49 +0200 Nikolay Aleksandrov wrote:
> TBH, keeping buggy code with a comment doesn't sound good to me. I'd rather
> remove this
> support than tell people "good luck, it might crash". It's better to be safe
> until a
> correct design is in place which takes care of these
>>> like
> >>>
> >>> ipsec->xs->xso.real_dev = real_dev;
> >>> __xfrm_state_delete
> >>> - bond_ipsec_del_sa()
> >>>
- bond_ipsec_free_sa()
- .xdo_dev_state_free()
.xdo_dev_state_add()
But there is no good solution yet. So I just added a FIXME note in here
and hope we can fix it in future.
Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to mutex")
Reported-by:
>>> like
>>>
>>> ipsec->xs->xso.real_dev = real_dev;
>>> __xfrm_state_delete
>>> - bond_ipsec_del_sa()
>>> - .xdo_dev_state_delete()
free()
> .xdo_dev_state_add()
>
> But there is no good solution yet. So I just added a FIXME note in here
> and hope we can fix it in future.
>
> Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to mutex")
> Reported-by: Jakub Kicinski
> Cl
On Wed, Mar 05, 2025 at 04:12:18PM +, Cosmin Ratiu wrote:
> +++ b/drivers/net/bonding/bond_main.c
> @@ -613,8 +613,11 @@ static void bond_ipsec_del_sa_all(struct bonding
> *bond)
>
> mutex_lock(&bond->ipsec_lock);
> list_for_each_entry(ipsec
This introduces a test for IPSec offload over bonding, utilizing netdevsim
for the testing process, as veth interfaces do not support IPSec offload.
The test will ensure that the IPSec offload functionality remains operational
even after a failover event occurs in the bonding configuration.
Here
The active-backup bonding mode supports XFRM ESP offload. However, when
a bond is added using command like `ip link add bond0 type bond mode 1
miimon 100`, the `ethtool -k` command shows that the XFRM ESP offload is
disabled. This occurs because, in bond_newlink(), we change bond link
first and
On Thu, Mar 06, 2025 at 01:37:15PM +, Cosmin Ratiu wrote:
> On Thu, 2025-03-06 at 10:02 +, Hangbin Liu wrote:
> > > For bond_ipsec_add_sa_all(), I will move the xso.real_dev =
> > > real_dev
> > > after .xdo_dev_state_add() in case the following situation.
>
> xso.real_dev needs to be init
nd_ipsec_add_sa_all(). e.g.
>
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 04b677d0c45b..3ada51c63207 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -537,15 +537,27 @@ static void bond
On Thu, 2025-03-06 at 10:02 +, Hangbin Liu wrote:
> > For bond_ipsec_add_sa_all(), I will move the xso.real_dev =
> > real_dev
> > after .xdo_dev_state_add() in case the following situation.
xso.real_dev needs to be initialized before the call to
xdo_dev_state_add, since many of the implementa
On Wed, Mar 05, 2025 at 04:12:18PM +, Cosmin Ratiu wrote:
> On Wed, 2025-03-05 at 14:13 +, Hangbin Liu wrote:
> > On Wed, Mar 05, 2025 at 10:38:36AM +0200, Nikolay Aleksandrov wrote:
> > > > @@ -617,8 +614,18 @@ static void bond_ipsec_del_sa_all(struct
real_dev to NULL? I checked,
> > real_dev is not used anywhere on the free calls, I think. I have
> > another series refactoring things around real_dev, I hope to be able to
> > send it soon.
> >
> > Here's a sketch of this idea:
> >
When validation on the backup slave is enabled, we need to validate the
Neighbor Solicitation (NS) messages received on the backup slave. To
receive these messages, the correct destination MAC address must be added
to the slave. However, the target in bonding is a unicast address, which
we cannot
The correct mac address for NS target 2001:db8::254 is 33:33:ff:00:02:54,
not 33:33:00:00:02:54. The same with client maddress.
Fixes: 86fb6173d11e ("selftests: bonding: add ns multicast group testing")
Acked-by: Jay Vosburgh
Reviewed-by: Nikolay Aleksandrov
Signed-off-by: H
The mac address on backup slave should be convert from Solicited-Node
Multicast address, not from bonding unicast target address.
v4: no change, just repost.
v3: also fix the mac setting for slave_set_ns_maddr. (Jay)
Add function description for slave_set_ns_maddr/slave_set_ns_maddrs (Jay)
v2
On Wed, 5 Mar 2025 08:25:07 + Hangbin Liu wrote:
> Could you help process it, or should I re-post it?
Repost.
On Wed, 2025-03-05 at 14:13 +, Hangbin Liu wrote:
> On Wed, Mar 05, 2025 at 10:38:36AM +0200, Nikolay Aleksandrov wrote:
> > > @@ -617,8 +614,18 @@ static void bond_ipsec_del_sa_all(struct
> > > bonding *bond)
> > >
> > > mutex_lock(&bond->
On Wed, Mar 05, 2025 at 10:38:36AM +0200, Nikolay Aleksandrov wrote:
> > @@ -617,8 +614,18 @@ static void bond_ipsec_del_sa_all(struct bonding *bond)
> >
> > mutex_lock(&bond->ipsec_lock);
> > list_for_each_entry(ipsec, &bond->ipsec_list, lis
Hangbin Liu writes:
> This introduces a test for IPSec offload over bonding, utilizing netdevsim
> for the testing process, as veth interfaces do not support IPSec offload.
> The test will ensure that the IPSec offload functionality remains operational
> even after a failover eve
rom bond->ipsec list.
>
> At the same time, protect bond_ipsec_del_sa_all and bond_ipsec_add_sa_all
> with x->lock for each xs being processed. This prevents XFRM from
> concurrently initiating add/delete operations on the managed states.
>
> Fixes: 2aeeef906d5a ("bonding: change i
ess on backup slave should be convert from Solicited-Node
> Multicast address, not from bonding unicast target address.
>
> v3: also fix the mac setting for slave_set_ns_maddr. (Jay)
> Add function description for slave_set_ns_maddr/slave_set_ns_maddrs (Jay)
> v2: fix patch 01&#
The active-backup bonding mode supports XFRM ESP offload. However, when
a bond is added using command like `ip link add bond0 type bond mode 1
miimon 100`, the `ethtool -k` command shows that the XFRM ESP offload is
disabled. This occurs because, in bond_newlink(), we change bond link
first and
This introduces a test for IPSec offload over bonding, utilizing netdevsim
for the testing process, as veth interfaces do not support IPSec offload.
The test will ensure that the IPSec offload functionality remains operational
even after a failover event occurs in the bonding configuration.
Here
concurrently initiating add/delete operations on the managed states.
Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to mutex")
Reported-by: Jakub Kicinski
Closes: https://lore.kernel.org/netdev/20241212062734.182a0...@kernel.org
Suggested-by: Cosmin Ratiu
Signed-off-by: Hangbin
On Tue, 2025-03-04 at 09:18 +, Hangbin Liu wrote:
>
> Just to make sure I added the lock in correct place, would you please
> help
> confirm.
>
> diff --git a/drivers/net/bonding/bond_main.c
> b/drivers/net/bonding/bond_main.c
> index e85878b12376..c59ad3a5cf43 10
del_sa_all
> is called in parallel, doesn't call delete on xs (because it's dead),
> then calls free (incorrect without delete first), then removes the list
> entry. Later, xdo_dev_state_delete( == bond_ipsec_del_sa) is called,
> and calls delete (incorrect, out of order with
Hi Cosmin,
On Fri, Feb 28, 2025 at 10:31:58AM +, Cosmin Ratiu wrote:
> On Fri, 2025-02-28 at 02:20 +, Hangbin Liu wrote:
> > On Thu, Feb 27, 2025 at 03:31:01PM +0200, Nikolay Aleksandrov wrote:
> > > > > One more thing - note I'm not an xfrm expert by far but it
> > > > > seems to me here y
On 2/28/25 13:07, Nikolay Aleksandrov wrote:
> On 2/28/25 12:31, Cosmin Ratiu wrote:
>> On Fri, 2025-02-28 at 02:20 +, Hangbin Liu wrote:
>>> On Thu, Feb 27, 2025 at 03:31:01PM +0200, Nikolay Aleksandrov wrote:
>> One more thing - note I'm not an xfrm expert by far but it
>> seems to me
On 2/28/25 12:31, Cosmin Ratiu wrote:
> On Fri, 2025-02-28 at 02:20 +, Hangbin Liu wrote:
>> On Thu, Feb 27, 2025 at 03:31:01PM +0200, Nikolay Aleksandrov wrote:
> One more thing - note I'm not an xfrm expert by far but it
> seems to me here you have
> to also call xdo_dev_state_fr
On Fri, 2025-02-28 at 02:20 +, Hangbin Liu wrote:
> On Thu, Feb 27, 2025 at 03:31:01PM +0200, Nikolay Aleksandrov wrote:
> > > > One more thing - note I'm not an xfrm expert by far but it
> > > > seems to me here you have
> > > > to also call xdo_dev_state_free() with the old active slave
> >
x27;m a bit lot here.
> >
> > Thanks
> > Hangbin
>
> Well, the race is between the xfrm GC and del_sa_all, in bond's free_sa if you
> walk the list under the mutex before calling real_dev's free callback and
> don't find the current element that's bein
Hangbin Liu writes:
> This introduces a test for IPSec offload over bonding, utilizing netdevsim
> for the testing process, as veth interfaces do not support IPSec offload.
> The test will ensure that the IPSec offload functionality remains operational
> even after a failover eve
On 2/27/25 15:21, Hangbin Liu wrote:
> On Thu, Feb 27, 2025 at 11:21:51AM +0200, Nikolay Aleksandrov wrote:
>>>> @@ -617,6 +611,12 @@ static void bond_ipsec_del_sa_all(struct bonding
>>>> *bond)
>>>>
>>>>mutex_lock(&bond->ipsec_l
On Thu, Feb 27, 2025 at 11:21:51AM +0200, Nikolay Aleksandrov wrote:
> >> @@ -617,6 +611,12 @@ static void bond_ipsec_del_sa_all(struct bonding
> >> *bond)
> >>
> >>mutex_lock(&bond->ipsec_lock);
> >>list_for_each_entry(ipsec, &
).
>>
>> In all three cases, xdo_dev_state_free() should not be called, only xs
>> should be removed from bond->ipsec list.
>>
>> Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to mutex")
>> Reported-by: Jakub Kicinski
&g
ged to a new device. At the same time, the xs is marked as DEAD
> due to the XFRM entry is removed, triggering xfrm_state_gc_task() and
> bond_ipsec_free_sa().
>
> In all three cases, xdo_dev_state_free() should not be called, only xs
> should be removed from bond->ip
This introduces a test for IPSec offload over bonding, utilizing netdevsim
for the testing process, as veth interfaces do not support IPSec offload.
The test will ensure that the IPSec offload functionality remains operational
even after a failover event occurs in the bonding configuration
The active-backup bonding mode supports XFRM ESP offload. However, when
a bond is added using command like `ip link add bond0 type bond mode 1
miimon 100`, the `ethtool -k` command shows that the XFRM ESP offload is
disabled. This occurs because, in bond_newlink(), we change bond link
first and
() and
bond_ipsec_free_sa().
In all three cases, xdo_dev_state_free() should not be called, only xs
should be removed from bond->ipsec list.
Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to mutex")
Reported-by: Jakub Kicinski
Closes: https://lor
On Wed, 2025-02-26 at 12:07 +, Hangbin Liu wrote:
>
> During bonding testing, we also found a case that would trigger
> the WARN_ON(xs->xso.real_dev != real_dev).
>
> If we create active-backup mode bonding and create ipsec tunnel over
> bonding device, then remove bondi
anks for proposing it. Maybe you should
> package it in a new submission with a proper title/etc.?
> I'll do the initial review here.
This is a draft patch and I think there may have something need to be fixed.
So I just paste it here :)
>
> >
> > diff --git a/driv
M_STATE_DEAD
> > in bond_ipsec_del_sa_all.
> >
> > What do you think about this idea?
>
> Thanks a lot for the comments. I also skipped the DEAD xs in
> add_sa_all.
> What about the patch like:
This is what I had in mind, thanks for proposing it. Maybe you should
pa
in add_sa_all.
What about the patch like:
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index e45bba240cbc..0e4db43a833a 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -537,6 +537,12 @@ static void bond_ipsec_add_sa_all(str
t;
>> Fix this by moving the mutex_lock() operation to a work queue.
>>
>> Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to
>> mutex")
>> Reported-by: Jakub Kicinski
>> Closes:
>> https://lore.kernel.org/netdev/20241212062734.18
ork queue.
>
> Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to
> mutex")
> Reported-by: Jakub Kicinski
> Closes:
> https://lore.kernel.org/netdev/20241212062734.182a0...@kernel.org
> Signed-off-by: Hangbin Liu
> ---
> drivers/net/bonding/bond_m
On 2/25/25 15:13, Hangbin Liu wrote:
> On Tue, Feb 25, 2025 at 01:05:24PM +0200, Nikolay Aleksandrov wrote:
>>> @@ -592,15 +611,17 @@ static void bond_ipsec_del_sa(struct xfrm_state *xs)
>>> real_dev->xfrmdev_ops->xdo_dev_state_delete(xs);
>>> out:
>>> netdev_put(real_dev, &tracker);
>>> -
On Tue, Feb 25, 2025 at 01:05:24PM +0200, Nikolay Aleksandrov wrote:
> > @@ -592,15 +611,17 @@ static void bond_ipsec_del_sa(struct xfrm_state *xs)
> > real_dev->xfrmdev_ops->xdo_dev_state_delete(xs);
> > out:
> > netdev_put(real_dev, &tracker);
> > - mutex_lock(&bond->ipsec_lock);
> > -
On 2/25/25 11:40, Hangbin Liu wrote:
> The fixed commit placed mutex_lock() inside spin_lock_bh(), which triggers
> a warning like:
>
> BUG: sleeping function called from invalid context at...
>
> Fix this by moving the mutex_lock() operation to a work queue.
>
> Fixes
This introduces a test for IPSec offload over bonding, utilizing netdevsim
for the testing process, as veth interfaces do not support IPSec offload.
The test will ensure that the IPSec offload functionality remains operational
even after a failover event occurs in the bonding configuration
The active-backup bonding mode supports XFRM ESP offload. However, when
a bond is added using command like `ip link add bond0 type bond mode 1
miimon 100`, the `ethtool -k` command shows that the XFRM ESP offload is
disabled. This occurs because, in bond_newlink(), we change bond link
first and
The fixed commit placed mutex_lock() inside spin_lock_bh(), which triggers
a warning like:
BUG: sleeping function called from invalid context at...
Fix this by moving the mutex_lock() operation to a work queue.
Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to mutex"
On 2/7/25 11:29, Hangbin Liu wrote:
> The mac address on backup slave should be convert from Solicited-Node
> Multicast address, not from bonding unicast target address.
>
> v3: also fix the mac setting for slave_set_ns_maddr. (Jay)
> Add function description for sla
Hangbin Liu wrote:
>The mac address on backup slave should be convert from Solicited-Node
>Multicast address, not from bonding unicast target address.
>
>v3: also fix the mac setting for slave_set_ns_maddr. (Jay)
>Add function description for slave_set_ns_maddr/slave_set_ns_m
Hi Jay,
Any comments?
Thanks
Hangbin
On Tue, Feb 11, 2025 at 07:31:32AM +, Hangbin Liu wrote:
> Hi Jay,
> On Sat, Feb 08, 2025 at 06:34:21AM +, Hangbin Liu wrote:
> > Please hold on this patch. Our QE reported that with bare NIC, the
> > backup NIC can't receive the NS messages even after
Hi Jay,
On Sat, Feb 08, 2025 at 06:34:21AM +, Hangbin Liu wrote:
> Please hold on this patch. Our QE reported that with bare NIC, the
> backup NIC can't receive the NS messages even after joining the multicast
> MAC group. But after remove the backup NIC from bond, the NIC interface
> could rec
olicited-Node
> Multicast address, not from bonding unicast target address.
>
> v3: also fix the mac setting for slave_set_ns_maddr. (Jay)
> Add function description for slave_set_ns_maddr/slave_set_ns_maddrs (Jay)
> v2: fix patch 01's subject
>
> Hangbin Liu (2):
> bon
The correct mac address for NS target 2001:db8::254 is 33:33:ff:00:02:54,
not 33:33:00:00:02:54. The same with client maddress.
Fixes: 86fb6173d11e ("selftests: bonding: add ns multicast group testing")
Signed-off-by: Hangbin Liu
---
tools/testing/selftests/drivers/net/bonding/bond_
When validation on the backup slave is enabled, we need to validate the
Neighbor Solicitation (NS) messages received on the backup slave. To
receive these messages, the correct destination MAC address must be added
to the slave. However, the target in bonding is a unicast address, which
we cannot
The mac address on backup slave should be convert from Solicited-Node
Multicast address, not from bonding unicast target address.
v3: also fix the mac setting for slave_set_ns_maddr. (Jay)
Add function description for slave_set_ns_maddr/slave_set_ns_maddrs (Jay)
v2: fix patch 01's su
On Thu, Feb 06, 2025 at 05:19:34PM -0800, Jay Vosburgh wrote:
> I think this now deserves some commentary in the code. Not
> because this function itself is unclear, but because there's the
> similarly-named slave_set_ns_maddr() (singular, not plural as in this
> patch) that will behave in a
Hangbin Liu wrote:
>When validation on the backup slave is enabled, we need to validate the
>Neighbor Solicitation (NS) messages received on the backup slave. To
>receive these messages, the correct destination MAC address must be added
>to the slave. However, the target in bonding
The correct mac address for NS target 2001:db8::254 is 33:33:ff:00:02:54,
not 33:33:00:00:02:54. The same with client maddress.
Fixes: 86fb6173d11e ("selftests: bonding: add ns multicast group testing")
Signed-off-by: Hangbin Liu
---
tools/testing/selftests/drivers/net/bonding/bond_
When validation on the backup slave is enabled, we need to validate the
Neighbor Solicitation (NS) messages received on the backup slave. To
receive these messages, the correct destination MAC address must be added
to the slave. However, the target in bonding is a unicast address, which
we cannot
The mac address on backup slave should be convert from Solicited-Node
Multicast address, not from bonding unicast target address.
v2: fix patch 01's subject
Hangbin Liu (2):
bonding: fix incorrect MAC address setting to receive NS messages
selftests: bonding: fix incorrect mac ad
the NS target's corresponding MAC address. But the target in
> bonding is a unicast addresses. We can't use it directly. Instead, we should
> convert it to a Solicited-Node Multicast Address first and then convert
> the multicast address to the right MAC address.
>
> Fixes: 8eb361
The correct mac address for NS target 2001:db8::254 is 33:33:ff:00:02:54,
not 33:33:00:00:02:54. The same with client maddress.
Fixes: 86fb6173d11e ("selftests: bonding: add ns multicast group testing")
Signed-off-by: Hangbin Liu
---
tools/testing/selftests/drivers/net/bonding/bond_
In order to receive the neighbor solicitation messages on the backup slave,
we should add the NS target's corresponding MAC address. But the target in
bonding is a unicast addresses. We can't use it directly. Instead, we should
convert it to a Solicited-Node Multicast Address firs
The mac address on backup slave should be convert from Solicited-Node
Multicast address, not from bonding unicast target address.
Hangbin Liu (2):
bonding: fix incorrect MAC address setting to receive NA messages
selftests: bonding: fix incorrect mac address
drivers/net/bonding
On Fri, 24 Jan 2025 16:03:32 + Cosmin Ratiu wrote:
> On Fri, 2025-01-24 at 07:38 -0800, Jakub Kicinski wrote:
> > On Thu, 23 Jan 2025 15:24:37 + Cosmin Ratiu wrote:
> > > I've sent another patch to suggest these changes.
> >
> > FTR this is not the normal way to proceed in code review,
On Fri, 2025-01-24 at 07:38 -0800, Jakub Kicinski wrote:
> On Thu, 23 Jan 2025 15:24:37 + Cosmin Ratiu wrote:
> > I've sent another patch to suggest these changes.
>
> FTR this is not the normal way to proceed in code review,
> please try to share your feedback rather than taking over
> the su
On Thu, 23 Jan 2025 15:24:37 + Cosmin Ratiu wrote:
> I've sent another patch to suggest these changes.
FTR this is not the normal way to proceed in code review,
please try to share your feedback rather than taking over
the submission (unless the original author explicitly asks
you to).
1 - 100 of 1115 matches
Mail list logo
