Re: [PATCH bpf-next 0/4] monitor network traffic for flaky test cases

[Stanislav Fomichev <sdf@fomichev.me>]

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).