From: Brett Sheffield <bacs@librecast.net>
To: Simon Horman <horms@kernel.org>
Cc: Oscar Maes <oscmaes92@gmail.com>,
netdev@vger.kernel.org, kuba@kernel.org, pabeni@redhat.com,
davem@davemloft.net, dsahern@kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH net v4] selftests: net: add test for destination in broadcast packets
Date: Fri, 29 Aug 2025 15:11:20 +0200 [thread overview]
Message-ID: <aLGm-G1JFxKH-jw5@karahi.gladserv.com> (raw)
In-Reply-To: <20250829111921.GI31759@horms.kernel.org>
On 2025-08-29 12:19, Simon Horman wrote:
> On Thu, Aug 28, 2025 at 01:42:42PM +0200, Oscar Maes wrote:
> > Add test to check the broadcast ethernet destination field is set
> > correctly.
> >
> > This test sends a broadcast ping, captures it using tcpdump and
> > ensures that all bits of the 6 octet ethernet destination address
> > are correctly set by examining the output capture file.
> >
> > Signed-off-by: Oscar Maes <oscmaes92@gmail.com>
> > Co-authored-by: Brett A C Sheffield <bacs@librecast.net>
>
> ...
>
> > +test_broadcast_ether_dst() {
> > + local rc=0
> > + CAPFILE=$(mktemp -u cap.XXXXXXXXXX)
> > + OUTPUT=$(mktemp -u out.XXXXXXXXXX)
> > +
> > + echo "Testing ethernet broadcast destination"
> > +
> > + # start tcpdump listening for icmp
> > + # tcpdump will exit after receiving a single packet
> > + # timeout will kill tcpdump if it is still running after 2s
> > + timeout 2s ip netns exec "${CLIENT_NS}" \
> > + tcpdump -i link0 -c 1 -w "${CAPFILE}" icmp &> "${OUTPUT}" &
> > + pid=$!
> > + slowwait 1 grep -qs "listening" "${OUTPUT}"
> > +
> > + # send broadcast ping
> > + ip netns exec "${CLIENT_NS}" \
> > + ping -W0.01 -c1 -b 255.255.255.255 &> /dev/null
> > +
> > + # wait for tcpdump for exit after receiving packet
> > + wait "${pid}"
>
> Hi Oscar and Brett,
>
> I am concerned that if something goes wrong this may block forever.
> Also, I'm wondering if this test could make use of the tcpdump helpers
> provided in tools/testing/selftests/net/forwarding/lib.sh
Thanks for the review Simon. Further to previous email after some more thought
and poking at lib.sh
We're starting tcpdump with -c1 so that it exits immediately when the packet is
received, and we catch this with the wait() so that, in the best case, we
continue immediately, and in the worse case the `timeout 2s` kills tcpdump and
we move on to cleanup. I *think* this is pretty safe.
Taking a look at the forwarding/lib.sh it looks like we could use
tcpdump_start() and pass in $TCPDUMP_EXTRA_FLAGS but I don't think this buys us
much here, as we'd still need to wait() or a sleep() or otherwise detect that
tcpdump is finished so we can continue. I don't see anything in lib.sh to aid us
with that?
That said, it might be good to use the helper function anyway and keep the
wait() for consistency. There don't seem to be many tests using the tcpdump
helper functions yet, but it's probably the right way to move.
What do you think, Oscar? It looks like lib.sh tcpdump_start() takes all the
arguments, including for your namespaces. Up to you if you want to call that
instead.
Now I know it's there, I'll try to use that for future tests.
I don't *think* there's anything here that needs a v4, unless the timeout() call
is thought to be insufficient to kill tcpdump. There's a -k switch if we want
to SIGKILL it :-)
> > +
> > + # compare ethernet destination field to ff:ff:ff:ff:ff:ff
> > + ether_dst=$(tcpdump -r "${CAPFILE}" -tnne 2>/dev/null | \
> > + awk '{sub(/,/,"",$3); print $3}')
> > + if [[ "${ether_dst}" == "ff:ff:ff:ff:ff:ff" ]]; then
> > + echo "[ OK ]"
> > + rc="${ksft_pass}"
> > + else
> > + echo "[FAIL] expected dst ether addr to be ff:ff:ff:ff:ff:ff," \
> > + "got ${ether_dst}"
> > + rc="${ksft_fail}"
> > + fi
> > +
> > + return "${rc}"
> > +}
>
> ...
--
Brett Sheffield (he/him)
Librecast - Decentralising the Internet with Multicast
https://librecast.net/
https://blog.brettsheffield.com/
next prev parent reply other threads:[~2025-08-29 13:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-28 11:42 [PATCH net v4] selftests: net: add test for destination in broadcast packets Oscar Maes
2025-08-28 12:16 ` Brett A C Sheffield
2025-08-29 11:19 ` Simon Horman
2025-08-29 11:44 ` Brett Sheffield
2025-08-29 13:11 ` Brett Sheffield [this message]
2025-09-01 12:25 ` Oscar Maes
2025-09-02 8:49 ` Paolo Abeni
2025-09-02 9:33 ` Brett Sheffield
2025-09-02 9:57 ` Paolo Abeni
2025-09-02 10:25 ` Brett Sheffield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aLGm-G1JFxKH-jw5@karahi.gladserv.com \
--to=bacs@librecast.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oscmaes92@gmail.com \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).