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