Re: [PATCH net v4] sctp: carry peer capabilities across an INIT collision

[Warren Briggs]

Hi Xin,

On Thu, 1 Oct 2026 at 12:11, Xin Long <lucien.xin@xxxxxxxxx> wrote:
>
> On Thu, Oct 1, 2026 at 3:05 AM <netdev-bot+sashiko@xxxxxxxxxx> wrote:
> >
> > [Severity: Low]
> > The commit message describes this as an INIT collision fix, but doesn't
> > the same code also run on a peer restart?
> >
> > Could the commit message describe the restart path too, and could that
> > path be tested?

Yes. The commit message will cover both callers, the INIT collision
(dupcook_b) and the peer restart (dupcook_a). The v4 testing covered the
collision only; v5 will add a peer restart test, with ASCONF and
RE-CONFIG sent from the surviving association after the restart, and v4
run as the control. I may need a couple of weeks to get to this.

> > [Severity: Medium]
> > On the peer restart path (sctp_sf_do_dupcook_a()->sctp_assoc_update(),
> > state >= SCTP_STATE_ESTABLISHED), only the inbound counters are
> > re-derived here. Shouldn't the outbound counters asoc->addip_serial and
> > asoc->strreset_outseq be updated as well?
> >
> > Should the ESTABLISHED branch take addip_serial and strreset_outseq from
> > new, next to next_tsn?
> >
> This looks a legit one.
>
> Since asoc->peer.asconf_capable and asoc->peer.reconf_capable are updated,
> we should address it in the same patch.
>
> So please follow the report above to update addip_serial and strreset_outseq in
> the ESTABLISHED branch.

Agreed. v5 will take asoc->addip_serial and asoc->strreset_outseq from
new in the ESTABLISHED branch, next to next_tsn. On restart
sctp_tietags_populate() keeps our initial_tsn and sctp_unpack_cookie()
bases both counters on it, so new already holds the values the
restarted peer expects.

pw-bot: cr

Warren