| Newsgroups |
dev.linux.lists.mptcp |
| Message-ID |
<[email protected]> |
August 13, 2026 at 5:20 PM, "Matthieu Baerts" <[email protected] mailto:[email protected]?to=%22Matthieu%20Baerts%22%20%3Cmatttbe%40kernel.org%3E > wrote:
>
> Hi Gang,
>
> On 13/08/2026 10:59, [email protected] wrote:
>
> >
> > August 13, 2026 at 3:57 PM, "Paolo Abeni" <[email protected] mailto:[email protected]?to=%22Paolo%20Abeni%22%20%3Cpabeni%40redhat.com%3E > wrote:
> >
> (...)
>
> >
> > >
> > > 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.
> > >
> >
> > Hi Paolo,
> >
> > That reminds me of an issue when I was reading mptcp_connect.c a long
> > time ago:
> >
> > At the end of 'sock_connect_mptcp()', it calls 'freeaddrinfo(addr)',
> > the 'peer' pointer (which points into 'addr') remains. Later, the main loop
> > uses this peer pointer for reconnection attempts. If the memory has been freed
> > and reused, the address data could be overwritten, resulting in an invalid
> > remote address.
> >
> > That might cause the hangs or failures you are seeing, right?
> >
> Good catch!
>
> Are you working on a fix for that? I guess we should copy the content,
> not just the pointer. Or maybe we don't need to do this copy:
> getaddrinfo() should return the same thing, no?
Hi Matt
I can working on this right now – and with the help of AI, I believe we can resolve
it quickly. :)
Thanks
Gang
>
> Cheers,
> Matt
> --
> Sponsored by the NGI0 Core fund.
>