Wei Yongjun wrote: > Vlad Yasevich wrote: >> Wei Yongjun wrote: >> >>> Vlad Yasevich wrote: >>> >>>> NACK >>>> >>>> Section 8.4: >>>> >>>> An SCTP packet is called an "out of the blue" (OOTB) packet if it is >>>> correctly formed (i.e., passed the receiver's CRC32c check; see >>>> Section 6.8), but the receiver is not able to identify the >>>> association to which this packet belongs. >>>> >>>> >>>> I would argue that the packet is not correctly formed in this case >>>> and deserves a protocol violation ABORT in return. >>>> >>>> -vlad >>>> >>> As your comment, patch has been changed. >>> Patch has been split to two, one is resolve this dead loop problem in >>> this mail. >>> And the other is come in another mail to discard partial chunk which >>> chunk length is set to zero. >>> >> >> >> I am starting to question the entire OOTB packet handling. There are way >> too many function that do almost the same thing and all handle OOTB a >> little >> different. >> >> sctp_sf_do_9_2_reshutack() is also called during sctp_sf_do_dupcook_a() >> processing, so checking for INIT chunk is wrong. Checking for just the >> chunkhdr_t should be enough. >> > This has been changed. >> sctp_sf_tabort_8_4_8 is used directly as well (not just through the state >> machine). Not sure if the header verification is appropriate. >> > It is needed. Because sctp_sf_tabort_8_4_8() is called to handle OOTB > packet before check the header length.
But now we are doing the same thing twice (and this is not the only place). I know I am being really picky here, but I am starting to thing the ootb handling\ is a mess and I really don't want to add to the mess. Until I (or someone else) prove that it's not a mess or fix it, I am going to hold off on these patches. Feel free to go through the spec and fix all the OOTB handling. Thanks -vlad - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
