Re: CI failures on nipa

Hi Paolo,

On 13/08/2026 09:57, Paolo Abeni wrote:
> I'm looking at this one:
> 
> https://netdev-ctrl.bots.linux.dev/logs/vmksft/mptcp/results/776501/6-mptcp-connect-sh/

I was looking at that too, last night between two mosquitoes :)
> the output is strange:
> 
> https://netdev-ctrl.bots.linux.dev/logview.html?f=/logs/vmksft/mptcp/results/776501/6-mptcp-connect-sh/stdout#L114
> 
> the first nstat dump includes apparently the counters from all the
> previous runs, which is unexpected: the nstat_init/nstat_get/pr_nstat
> dance should allow showing the data from current run only right?

Ah yes, indeed. mptcp_lib_pr_nstat() is not looking at the nstat
history, taking data from the beginning instead of the last time
nstat_init was executed (same for mptcp_lib_get_counter()).

I can send a fix for that.

> Also I think mptcp_lib_wait_timeout completes too late (after ~60 secs),
> when the listener already bailed out due to accept timeout (after ~30
> secs), so it does not show any info on the listener side. I fear it may
> also race with the actuall `timeout` command completion showing socket
> states after the user-space program completion.

Do you mean you would like to have mptcp_lib_wait_timeout wait for less
than the accept timeout?

mptcp_lib_wait_timeout has been introduced to dump the counters when
mptcp_connect stalls, and even the poll timeout didn't help.

What about modifying mptcp_connect.c to dump counters -- only for its
netns -- before exiting in case of timeout?

> Judging on the final status, I *think*/*guess* the (re)connect is
> hanged, possibly due to bad remote address?!? It could be useful to
> print out on stderr the reconnect destination address.
Strange why would it be only visible now? But yes, as Gang said, it
looks like a free is done on the addresses in between.

(When I checked last night, I was initially thinking about an issue with
a Netdev pending patch -- maybe even one related to TCP as it was
visible even with connections from TCP to MPTCP -- because this wasn't
visible on our CI, but maybe not.)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.