On 7/15/24 20:25, Stanislav Fomichev wrote:
On 07/15, Kui-Feng Lee wrote:
On 7/15/24 16:56, Martin KaFai Lau wrote:
On 7/15/24 3:07 PM, Kui-Feng Lee wrote:
On 7/15/24 14:33, Stanislav Fomichev wrote:
On 07/12, Kui-Feng Lee wrote:
Run tcpdump in the background for flaky test cases related to network
features.
Have you considered linking against libpcap instead of shelling out
to tcpdump? As long as we have this lib installed on the runners
(likely?) that should be a bit cleaner than doing tcpdump.. WDYT?
I just checked the script building the root image for vmtest. [1]
It doesn't install libpcap.
If our approach is to capture the packets in a file, and let developers
download the file, it would be a simple and straight forward solution.
If we want a log in text, it would be more complicated to parse
packets.
Martin & Stanislay,
WDYT about capture packets in a file and using libpcap directly?
Developers can download the file and parse it with tcpdump locally.
thinking out loud...
Re: libpcap (instead of tcpdump) part. I am not very experienced in
libpcap. I don't have a strong preference. I do hope patch 1 could be
more straight forward that no need to use loops and artificial udp
packets to ensure the tcpdump is fully ready to capture. I assume using
libpcap can make this sync part easier/cleaner (pthread_cond?) and not
too much code is needed to use libpcap?
Yes, it would be easier and cleaner if we don't parse the payload
of packets.
Yeah, same, no strong preference; was just wondering whether you've
made a conscious choice of not using it because it definitely makes things
a bit easier wrt to the part where you try to sync with tcpdump..
Also +1 on saving the raw file (via libpcap or tcpdump -w).
I agree to do it with libpcap. And, will print a number to stdout/stderr
as an index to the packets in the raw file. However, I need to figure
out how to make the raw file available to developers at first.
