sctplab / stream-reset-improved Goto Github PK

When FreeBSD receives a INCOMING_SSN_RESET request it response with a OUTGOING_SSN_RESET, like in rfc deined, and a second RECONFIG RESPONSE parameter. The RECONFIG RESPONSE is not nessesary.

see testcase https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_or/sctp-sr-c-or-v-6-1.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_or/sctp-sr-c-or-v-7-1.pkt

FreeBSD doesn't stop the reconfig timer for a ssn/tsn reset request, if the response field is 0xffff. The response is not a valid result code but RFC 6525 said that at first an implementation should stop the reconfig timer regardless of which result is in the response parameter. If the result code is only 6 the reconfig time should be started again.
see tests
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-6-3.pkt

When FreeBSD enters the state deferred reset processing and gets further TSNs, it send a maleformed reconfig chunk after leaving the state. This happens only when the cum_tsn is greater than last_tsn after leaving the state deferred reset processing. FreeBSD 11 doesn't send a response. After it gets a retransmission FreeBSD 11 process the reset.
see also https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_or/sctp-sr-c-or-v-16-1.pkt

The RFC 6525 said that an application can't issue a reconfig request if the reconfig Timer is running. The implementation in FreeBSD doesn't check that the reconfig timer is running for OUTGOING_SSN_RESET request. The other requests can't be issued if the reconfig timer is running.
see tests
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rc/sctp-sr-c-rc-v-5-1.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rc/sctp-sr-c-rc-v-5-6.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rc/sctp-sr-c-rc-v-5-11.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rc/sctp-sr-c-rc-v-5-16.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rc/sctp-sr-c-rc-v-5-21.pkt

If an endpoint gets an ADD_INCOMING_STREAMS Request it must answer with a ADD_OUTGOING_STREAMS Request and a Response parametere. Because they can't put together in one reconfig chunk they must be send in two different chunks. If a Requests is received a second time, the endpoint must send the same reconfig chunk as response than to the first answer. In case of ADD_INCOMING_STREAMS are two chunks send but only one is send in response to the second request. That is no big problem because the requests would be retransmitted when the reconfig timer expires.

see https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rc/sctp-sr-c-rc-v-14-5.pkt

In some testcases it is nessesary to prove that all streams are added or reseted. For such tests therer will be packets received which are send to streams that doesn't exist. In that case FreeBSD should send an ERROR Chunk with invalid stream identifyer. FreeBSD doesn't send this error as response to every packet. It is send only every second time.
see also https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_ai/sctp-sr-c-ai-v-1-1.pkt

see https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_ir/sctp-sr-c-ir-v-6-1.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_ir/sctp-sr-c-ir-v-7-1.pkt
for more details.

If FreeBSD receives an ADD_OUTGOING_STREAMS request with 0 new streams, it responses with a reconfig response with result 1 performed. A better result is 0 "nothing to do", because there aren't any streams to add, so the implementation must do nothing.
see also https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rr/sctp-sr-c-rr-v-2-22.pkt

see also
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rc/sctp-sr-c-rc-v-9-1.pkt

When FreeBSD hasn't finished to send DATA for example because fragmentation, and then receives a SSN_TSN_RESET request, FreeBSD performes the reset and send reconfig response before it sends the last fragments. So the other endpoint isn't able to put the data fragments together.
see test
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-mf/sctp-sr-i-mf-i-2-8.pkt

If an application wants to reset streams and uses stream ids which are greater than the existing streams, FreeBSD doesn't returns an error when calling setsockopt syscall. If 10 streams exist, FreeBSD can put stream id 10 in syscall without an error. Stream id 11 throws an error.
see
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-i-8-3.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-i-8-5.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-i-8-7.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-i-8-9.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-i-8-11.pkt

The RFC 6525 describes the sctp_assoc_reset_event which will be delivered when an endpoint processes a SSN_TSN_RESET request. Therefor the implementation put the sender and receivers_next_tsn in the fields local_next_tsn and receivers_next_tsn. When the application gets the event both field are delivered plus 1.

see tests
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-ae/sctp-sr-api-ae-v-7-1.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-ae/sctp-sr-api-ae-v-7-2.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-ae/sctp-sr-api-ae-v-7-3.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-ae/sctp-sr-api-ae-v-7-4.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-ae/sctp-sr-api-ae-v-7-5.pkt

If FreeBSD receives a SSN/TSN RESET Reqeust bundled with DATA in one sctp packet, FreeBSD send in response to the DATA a SACK with the new TSN und reports DATA packet as a dup.
see tests
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-mf/sctp-sr-i-mf-i-6-3.pkt

FreeBSD process all combination of reconfig parameters in one reconfig chunk, also the combination of parameters that aren't allowed by the rfc.
see tests
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rc/sctp-sr-c-rc-o-11-1.pkt
and following tests sr-c-rc-o-11-

If an Application calls the setsockopt syscall with SCTP_ADD_STREAMS option to add 0 new incoming and 0 new outgoing streams, the syscall returns an error. The RFC doen't make any constraint for that values unless the limit of max streams. So that means that this would be a valid call.
Besides that both values 0 could be a legal combination without any effect.
see https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-as/sctp-sr-api-as-v-5-1.pkt

If FreeBSD receives an INCOMING SSN RESET while it has DATA outstanding because of fragmentation or other things, it send a reconfig Response with result 1 "performed". After FreeBSD has finished DATA transfer it send the OUTGOING_SSN_RESET. Thats not like RFC said, because of the aditional response. In my opinion is a better way to send a response with result 6 "in progress" like when receiving OUTGOING_SSN_RESET. Thats would use the same way like the other request.
see test
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-mf/sctp-sr-i-mf-i-2-2.pkt

See tests
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-9-5.pkt

The RFC 6525 says for the resp_sn field in Outgoing SSN Reset Request parameter, that an endpoint who receives it, must mark the request sequence number as acknowledged and stop if nessesary the reconfig Timer. FreeBSD doesn't mark the request sequence number as acknowledged if it belongs to a SSN/TSN Reset request.
see Test
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-mf/sctp-sr-i-mf-i-5-2.pkt

see tests
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-mf/sctp-sr-i-mf-v-11-7.pkt

For INCOMING_SSN_RESET requests when no requested SSN is greater than 0 FreeBSD should respond with RECONFIG RESPONSE with result 0 "nothing to do". FreeBSD actual sends OUTGOING_SSN_RESET for the reqeusted streams which is not nessesary.
See https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_ir/sctp-sr-c-ir-v-8-1.pkt for details.

If FreeBSD receives a SSN_TSN_RESET request but the implemenation hasn't allowed to process them, FreeBSD answers with a reconfig response without the additional fields sender_/receiver_next_tsn. If FreeBSD sends a result indicating an error both fields are added to the response parameter.
see also https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rr/sctp-sr-c-rr-v-2-20.pkt

When an endpoint issues two reconfig requests, for example INCOMING_SSN_RESET and OUTGOING_SSN_RESET, and they are answered with two responses in different reconfig chunks in decending order, FreeBSD doesn't stop the reconfig timer.
see also https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rr/sctp-sr-c-rr-v-8-5.pkt

The messageflow in RFC 6525 for Add Incoming Streams Requests is worng. In the messageflow showed in RFC 6525 there is a Reconfig Response missing which send the receiver of Add Incoming Streams Request. If it is missing, there is now way to stop the reconfig timer which is running for the Add Incoming Streams request. So the best way is to combine the Add Outgoing Stream Request with a Reconfig Response parameter in one Reconfig Chunk. So this combination must be add to the allowed combinations in the RFC.
E-A E-Z
----------------[RE-CONFIG(ADD_IN_STRMS:X/3)]----------------->
<----[RE-CONFIG(ADD_OUT_STRMS-REQ:Y/3,RESP:X)]------
---------------------------[RE-CONFIG(RESP:Y)]----------------------->
Else there is no information to stop reconfig timer. Therefore the combination of ADD_OUTGOING_STREAMS and RESPONSE must be put in list of allowed combinations of parameter.
see tests.
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-2-14.pkt

If FreeBSD receives a reconfig chunk with three parameters, it processes the first and the secodn parameter correctly. But it doesn't recognises that there is a third one. In Fact that there are only two parameters allowed, this reaction is ok. In my opinion the implementation can send error because only two parameters are allowed
see test
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-ip/sctp-sr-i-ip-i-4-1.pkt

FreeBSD doesn't check the stream ids in the socketoption SCTP_RESET_STREAMS which an application put in the stream id list. If the application puts dupplicate stream ids in the list the implementation sends the dupplicate stream ids in the INCOMING_SSN_RESET request´. Thats no big problem because reset on estream twice has no effect.
see
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-i-7-1.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-i-7-2.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-i-7-3.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-i-7-7.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-i-7-8.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-i-7-9.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-i-7-7.pkt

If an Endpoint has an ADD OUTGOING STREAMS Requests outstanding and than receives an Restet request for that new streams, FreeBSD sends a respons with result successful
see test
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-mf/sctp-sr-i-mf-i-4-2.pkt

RFC 6525 says for process of INCOMING SSN RESET that the receiver must copy all stream ids from the INCOMING to the OUTGOING SSN RESET requests. FreeBSD doesn't copy the stream ids if the INCOMING SSN RESET wants to reset all streams. Thats no functional error because no streams in the requests means all streams, but it is not implemented like defined in RFC.
see
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-se/sctp-sr-api-se-v-5-8.pkt

When FreeBSD receives an ADD_INCOMING_STREAMS request with 0 new streams, it responses with a reconfig response parameter and a scond empty reconfig chunk.
see also https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rr/sctp-sr-c-rr-v-4-4.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rr/sctp-sr-c-rr-v-6-4.pkt

If an endpoint sends an OUTGOING_SSN_RESET and receives then an INCOMING_SSN_RESET for other streams then in the OUTGOING_SSN_RESET request, the endpoint should process the INCOMING_SSN_RESET request normaly. FreeBSD answers to the INCOMING_SSN_RESET with a reconfig response and send an OUTGOING_SSN_RESET request after the first is finished. FreeBSD must immediately send the second OUTGOING_SSN_RESET request
see https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_ir/sctp-sr-c-ir-v-9-1.pkt
for more details

An application can enable SCTP_ENABLE_RESET_ASSOC_REQ flag to allow the implementation to process incoming SSN_TSN_RESET requests. In FreeBSD the implementation deny any incoming SSN_TSN_RESET requests if this flag is enable. But if SCTP_ENABLE_CHANGE_ASSOC_REQ is enabled than SUT delivers result 1 successful.

see also https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_sr/sctp-sr-c-sr-v-7-1.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_sr/sctp-sr-c-sr-v-9-1.pkt

For reconfig requests it makes only sense to be processed in sctp state ESTABLISHED. In most states FreeBSD discard all reconfig requests. But in state Cookie Wait it sends for all reconfig requests a response with result 5 "Bad sequence number".
see test
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-is/sctp-sr-i-is-i-2-7.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-is/sctp-sr-i-is-i-2-8.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-is/sctp-sr-i-is-i-2-9.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-is/sctp-sr-i-is-i-2-10.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-is/sctp-sr-i-is-i-2-11.pkt

If an endpoint send DATA and a Reconfig requests in one sctp packet, FreeBSD can handle the DATA packets only if they use the values like tsn and ssn after performing the reconfig request. This means in case of an OUTGOING SSN RESET request the DATA in the packet must use the new SSNs after the reset.
see test
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-mf/sctp-sr-i-mf-i-7-1.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-mf/sctp-sr-i-mf-i-7-2.pkt

If FreeBSD gets two Reconfig requests with the same reconfig request sequence number, FreeBSD send the same response to the second request than to the first. This is a RFC like reaction.

see tests sctp-sr-i-pv-13-1 to sctp-sr-i-pv-13-20
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-13-1.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-13-2.pkt
....

If an application calls the socketoption SCTP_RESET_STREMS with all existing stream ids for an INCOMING_SSN_RESET request, the implementation sends a requests with all stream ids in the list. If the application calls the syscall for an OUTGOING_SSN_RESET requests, the implementation sends an empty list. This reaction is not a big problem because it results in the same reset of all streams, but a similar reaction of both ways (INCOMIN and OUTGOING requests) would be nice.
see
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-v-6-7.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-v-6-9.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-v-6-25.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-rs/sctp-sr-api-rs-v-6-27.pkt

In RFC 6525 there are examples how an endpoint could calculate the values for the response fields sender next tsn and receiver next tsn. FreeBSD doesn't calculate both fields like the way described in the RFC.
see tests
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-mf/sctp-sr-i-mf-v-9-3.pkt

When an endpoint receives an OUTGOING_SSN_RESET with last_tsn > cum_tsn it must enter state deferred reset processing. When it gets all TSNs that cum_tsn >= last_tsn it must leave the state and must perform the reset. FreeBSD r300201 doesn't send a response after it gets the last TSNs.
see
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-se/sctp-sr-api-se-v-2-6.pkt

This Issue describes that FreeBSD doesn't stops the reconfig Timer if two reconfig requests are send out and are answered in two different reconfig chunks in decending order. FreeBSD should mark both reconfig request sequence numbers as acknowledged and should stop the reconfig Timer after geting the second response.
see tests
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-12-1.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-12-2.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-12-3.pkt

If all SSNs are 0, FreeBSD sends result code 1 performed as response to an OUTGOING_SSN_RESET. A better result code is 0 "nothing to do".
see also https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rr/sctp-sr-c-rr-v-2-1.pkt

If FreeBSD 10.3 leaves the state deferred reset processing because fo receiving DATA with tsn = last_tsn, FreeBSD send two reconfig response parameter for the same request sequence number. The first has got result 6 "in progress" and the second the result "performed". Only the second parameter is nessesary. There is no negative effect of this error.
see also https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_or/sctp-sr-c-or-v-13-1.pkt

The result code 4 "alread in progress" is specified in RFC6525 but isn't used for any request type. It make sense to use the result code if an endpoint is in state deffered reset processing and receives a OUTGOING_SSN_RESET with same stream ids than the previous request wants to reset.
see also https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rr/sctp-sr-c-rr-v-2-5.pkt

For a Reconfig Response with result 6 "in progress" SUT at first should stop the reconfig timer, them mark the Request sequence number as acknowledged and then restart the reconfig timer. In case of the reconfig timer runs for a INCOMING_SSN_RESET, ADD_OUTGOING_STREAMS and ADD_INCOMING_STREAMS the reconfig timer is not restarted.
see also https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rr/sctp-sr-c-rr-v-10-2.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rr/sctp-sr-c-rr-v-10-4.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rr/sctp-sr-c-rr-v-10-5.pkt

When an Implementation receives a reconfig Response with the result 6 "in progress" the SUT must start the reconfig timer again after stoping it befor. When the reconfig timer expires the SUT must retransmitt the request but doesn't increment the error counter for the endpoint. FreeBSD increments the error count after receiving such a response.

see also https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rr/sctp-sr-c-rr-v-10-1.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rr/sctp-sr-c-rr-v-10-3.pkt

If an application issues a reconfig request, any new userdata, which should be send, must be queued and released after reconfig request is finished. In case of SSN_TSN_RESET the application can send new userdata while the reconfig timer is running.
see also https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_sr/sctp-sr-c-sr-v-3-1.pkt

If an other endpoint sends an Outgoing ssn reset request with stream ids, which are higher than the number of existing streams, FreeBSD send a reconfig response with result code 1 performed. SUT should send a response which denies the requests like it do when receiving INCOMING_SSN_RESET with higher sids
see tests
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-3-1.pkt

When FreeBSD receives a reconfig requests with a request sequence number = (initial tsn -1) it sends a response with the result 0 "nothing to do". In case of that the requests seqeunce number is never send bevor, the SUT should send a response with the result 5 "bad sequence number"
see tests
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-2-1.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-2-4.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-2-7.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-2-10.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-pv/sctp-sr-i-pv-i-2-13.pkt

The RFC 6525 says for the resp_sn field in Outgoing SSN Reset Request parameter, that an endpoint who receives it, must mark the request sequence number as acknowledged and stop if nessesary the reconfig Timer. There is no word for performing the whole actions like when receiving a reconfig response. FreeBSD performes the reset like OUTGOING SSN RESET when receiving an OUTGOING SSN RESET with the response sequence number for a OUTGOING SSN RESET. If the response sequence number belongs to an ADD OUTGOING STREAMS Request, FreeBSD adds the new streams.
That is a problem is a Response with a deny is lost on wire or a new OUTGOING SSN RESET is faster than the response. So the SUT performes a requests which is nor successful performed.
see test
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-mf/sctp-sr-i-mf-i-5-1.pkt
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-mf/sctp-sr-i-mf-i-5-3.pkt

FreeBSD 11 throws a kernel panic after processing a SSN_TSN_RESET. After that the testcase send some DATA to ensure that all stream SSNs are reseted to 0. Atfter processing the second new packet FreeBSD throws a kernel panic. This happend not every testrun. FreeBSD 10.3 stops sending DATA but OS os still working.
see testcase https://github.com/nplab/RFC6525_Testsuite/blob/master/conformance_tests/sctp_sr_c_rr/sctp-sr-c-rr-v-14-1.pkt

If FreeBSD buffers DATA because of nagle algorithm, and then receives a SSN_TSN_RESET requests it send the buffered DATA with new TSNs and old SSNs.
see test
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-mf/sctp-sr-i-mf-i-1-4.pkt

on FreeBSD 10.3 getsockopt returns 0
see test
https://github.com/nplab/RFC6525_Testsuite/blob/master/api_tests/sctp-sr-api-ra/sctp-sr-api-ra-v-2-1.pkt

If FreeBSD buffers DATA to send to the other endpoint, the application can't issue new SSN/TSN_RESET requests. The syscall setsockopt delivers -1.
see test
https://github.com/nplab/RFC6525_Testsuite/blob/master/implementation_tests/sctp-sr-i-mf/sctp-sr-i-mf-i-1-2.pkt