amt.sh flaking
Subsystems (2)
Jakub Kicinski
maintainerHi 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
Quoted 1 line · Jakub Kicinski
Hi Jakub,
Thanks a lot for the report!
Quoted 26 lines
Hi Taehee!
After migration to netdev foundation machines the
amt.shtest 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=1FWIW the new setup is based on Fedora 43 with:
Quoted 8 lines
# 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
Quoted 33 lines · Taehee Yoo
Quoted 1 line · Jakub Kicinski
Hi Jakub,
Thanks a lot for the report!Quoted 26 lines
Hi Taehee!
After migration to netdev foundation machines the
amt.shtest 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=1FWIW 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
Quoted 13 lines
Quoted 8 lines
# cat /etc/systemd/network/99-default.link [Match] OriginalName=*[Link]
NamePolicy=keep kernel database onboard slot path AlternativeNamesPolicy=database onboard slot path mac MACAddressPolicy=noneI will try to reproduce in my local machine then will try to fix this problem. Thanks a lot!
Taehee Yoo
Jakub Kicinski
maintainerQuoted 17 lines · On Wed, 14 Jan 2026 20:55:29 +0900 Taehee Yoo wrote:
Quoted 13 lines
Quoted 13 lines
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=1Quoted 1 line
Quoted 1 line
FWIW the new setup is based on Fedora 43 with:
Hi Jakub, Sorry for the late reply.
Quoted 9 lines
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!