[TEST] amt.sh flaking

[TEST] amt.sh flaking

[Jakub Kicinski]

Hi Taehee!

After migration to netdev foundation machines the amt.sh test has
gotten a bit more flaky:

https://netdev.bots.linux.dev/contest.html?test=amt-sh

In fact it's the second most flaky test we have after txtimestamp.sh.

All the failures are on non-debug kernels, and look like this:

TAP version 13
1..1
# timeout set to 3600
# selftests: net: amt.sh
# 0.26 [+0.26] TEST: amt discovery                                                 [ OK ]
# 15.27 [+15.01] 2026/01/05 19:33:27 socat[4075] W exiting on signal 15
# 15.28 [+0.01] TEST: IPv4 amt multicast forwarding                                 [FAIL]
# 17.30 [+2.02] TEST: IPv6 amt multicast forwarding                                 [ OK ]
# 17.30 [+0.00] TEST: IPv4 amt traffic forwarding torture               ..........  [ OK ]
# 19.48 [+2.18] TEST: IPv6 amt traffic forwarding torture               ..........  [ OK ]
# 26.71 [+7.22] Some tests failed.
not ok 1 selftests: net: amt.sh # exit=1

FWIW the new setup is based on Fedora 43 with:

# cat /etc/systemd/network/99-default.link
[Match]
OriginalName=*

[Link]
NamePolicy=keep kernel database onboard slot path
AlternativeNamesPolicy=database onboard slot path mac
MACAddressPolicy=none

Re: [TEST] amt.sh flaking

[Taehee Yoo]

On Tue, Jan 6, 2026 at 11:07 AM Jakub Kicinski <kuba@kernel.org> wrote:
>

Hi Jakub,
Thanks a lot for the report!

> Hi Taehee!
>
> After migration to netdev foundation machines the amt.sh test has
> gotten a bit more flaky:
>
> https://netdev.bots.linux.dev/contest.html?test=amt-sh
>
> In fact it's the second most flaky test we have after txtimestamp.sh.
>
> All the failures are on non-debug kernels, and look like this:
>
> TAP version 13
> 1..1
> # timeout set to 3600
> # selftests: net: amt.sh
> # 0.26 [+0.26] TEST: amt discovery                                                 [ OK ]
> # 15.27 [+15.01] 2026/01/05 19:33:27 socat[4075] W exiting on signal 15
> # 15.28 [+0.01] TEST: IPv4 amt multicast forwarding                                 [FAIL]
> # 17.30 [+2.02] TEST: IPv6 amt multicast forwarding                                 [ OK ]
> # 17.30 [+0.00] TEST: IPv4 amt traffic forwarding torture               ..........  [ OK ]
> # 19.48 [+2.18] TEST: IPv6 amt traffic forwarding torture               ..........  [ OK ]
> # 26.71 [+7.22] Some tests failed.
> not ok 1 selftests: net: amt.sh # exit=1
>
> FWIW the new setup is based on Fedora 43 with:
>
> # cat /etc/systemd/network/99-default.link
> [Match]
> OriginalName=*
>
> [Link]
> NamePolicy=keep kernel database onboard slot path
> AlternativeNamesPolicy=database onboard slot path mac
> MACAddressPolicy=none

I will try to reproduce in my local machine then will try to fix this problem.
Thanks a lot!

Taehee Yoo

Re: [TEST] amt.sh flaking

[Taehee Yoo]

On Tue, Jan 6, 2026 at 8:52 PM Taehee Yoo <ap420073@gmail.com> wrote:
>
> On Tue, Jan 6, 2026 at 11:07 AM Jakub Kicinski <kuba@kernel.org> wrote:
> >
>
> Hi Jakub,
> Thanks a lot for the report!
>
> > Hi Taehee!
> >
> > After migration to netdev foundation machines the amt.sh test has
> > gotten a bit more flaky:
> >
> > https://netdev.bots.linux.dev/contest.html?test=amt-sh
> >
> > In fact it's the second most flaky test we have after txtimestamp.sh.
> >
> > All the failures are on non-debug kernels, and look like this:
> >
> > TAP version 13
> > 1..1
> > # timeout set to 3600
> > # selftests: net: amt.sh
> > # 0.26 [+0.26] TEST: amt discovery                                                 [ OK ]
> > # 15.27 [+15.01] 2026/01/05 19:33:27 socat[4075] W exiting on signal 15
> > # 15.28 [+0.01] TEST: IPv4 amt multicast forwarding                                 [FAIL]
> > # 17.30 [+2.02] TEST: IPv6 amt multicast forwarding                                 [ OK ]
> > # 17.30 [+0.00] TEST: IPv4 amt traffic forwarding torture               ..........  [ OK ]
> > # 19.48 [+2.18] TEST: IPv6 amt traffic forwarding torture               ..........  [ OK ]
> > # 26.71 [+7.22] Some tests failed.
> > not ok 1 selftests: net: amt.sh # exit=1
> >
> > FWIW the new setup is based on Fedora 43 with:
> >

Hi Jakub, Sorry for the late reply.

The root cause is that the source sends packets before the connection
between the gateway and the relay is established. At that moment,
packets cannot reach the listener.
To fix this issue, the source needs to wait until the connection is
established. However, the current AMT module does not notify its
status to userspace. As a temporary workaround, I will send a patch
that adds a 5-second sleep just before “IPv4 AMT multicast forwarding.”
After that, I will work on adding status notifications to the AMT module
and to iproute2.

Thanks a lot!
Taehee Yoo

> > # cat /etc/systemd/network/99-default.link
> > [Match]
> > OriginalName=*
> >
> > [Link]
> > NamePolicy=keep kernel database onboard slot path
> > AlternativeNamesPolicy=database onboard slot path mac
> > MACAddressPolicy=none
>
> I will try to reproduce in my local machine then will try to fix this problem.
> Thanks a lot!
>
> Taehee Yoo

Re: [TEST] amt.sh flaking

[Jakub Kicinski]

On Wed, 14 Jan 2026 20:55:29 +0900 Taehee Yoo wrote:
> > > TAP version 13
> > > 1..1
> > > # timeout set to 3600
> > > # selftests: net: amt.sh
> > > # 0.26 [+0.26] TEST: amt discovery                                                 [ OK ]
> > > # 15.27 [+15.01] 2026/01/05 19:33:27 socat[4075] W exiting on signal 15
> > > # 15.28 [+0.01] TEST: IPv4 amt multicast forwarding                                 [FAIL]
> > > # 17.30 [+2.02] TEST: IPv6 amt multicast forwarding                                 [ OK ]
> > > # 17.30 [+0.00] TEST: IPv4 amt traffic forwarding torture               ..........  [ OK ]
> > > # 19.48 [+2.18] TEST: IPv6 amt traffic forwarding torture               ..........  [ OK ]
> > > # 26.71 [+7.22] Some tests failed.
> > > not ok 1 selftests: net: amt.sh # exit=1
> > >
> > > FWIW the new setup is based on Fedora 43 with:
> 
> Hi Jakub, Sorry for the late reply.
> 
> The root cause is that the source sends packets before the connection
> between the gateway and the relay is established. At that moment,
> packets cannot reach the listener.
> To fix this issue, the source needs to wait until the connection is
> established. However, the current AMT module does not notify its
> status to userspace. As a temporary workaround, I will send a patch
> that adds a 5-second sleep just before “IPv4 AMT multicast forwarding.”
> After that, I will work on adding status notifications to the AMT module
> and to iproute2.

Sounds great. I don't think that a single sleep 5 in this test would 
be a big deal but of course having a notification is better if you have
cycles to implement that. Thanks for looking into it!