last_cwr_tsn of the first net is initialized with a temporary TSN

[protodef]

Hello,

While using ECN feature, I found that, when usrsctp receives an ECN ECHO chunk from lksctp, usrsctp sometimes sends a ECN CWR chunk with totally irrelevant TSN to lksctp. This led lksctp to keep sending ECN ECHO chunk for each SCTP packet it sends.

So far, I found that last_cwr_tsn of the first net is initialized with a temporary TSN through the following steps.
(When usrsctp sends ECN CWR, last_cwr_tsn is used without update in some cases.)

1. In sctp_process_cookie_new(), a new association is created by sctp_aloc_assoc().
2. In sctp_aloc_assoc(), the newly allocated association is initialized by sctp_init_asoc().
3. In sctp_init_asoc(), init_seq_number and sending_seq of the association are initialized with a TSN (T1) that is generated by sctp_select_initial_TSN().
4. Back to sctp_aloc_assoc(), after sctp_init_asoc(), sctp_add_remote_addr() adds a net (N1) for the given address to the association. last_cwr_tsn of the net (N1) is set to sending_seq - 1. (Here, sending_seq is T1.)
5. Back to sctp_process_cookie_new() after sctp_aloc_assoc(), init_seq_number and sending_seq of the association are set to the TSN (T2) in initack_cp.
6. Next, in sctp_process_cookie_new(), sctp_load_addresses_from_init() adds nets (N?) that will have last_cwr_tsn that is set to sending_seq - 1 but here, sending_seq is now T2.

Because I'm fairly new to SCTP, I'm not sure this is intended or not. Would you take a look at this?

[tuexen]

I'll look at this. Please note that ECN hasn't been much (if at all) tested recently...

[tuexen]

Please test and report if the above fix addresses the initialisation issue you reported.

Thanks for reporting!