>>       i looked at it.
>I presume when you say "it" you do not mean "the idea of the counter",
>but rather "the behavior of tcp_dooptions()"?

	i tried to add a counter increment logic into tcp_dooptions(),
	and found that tcp_dooptions() need some cleanups.

>>  it looks to me we need to do it carefully, including:
>>       - tcp_dooptions does not raise error on invalid options or whatever
>>         (return type is void).
>I'm not sure what a "whatever" is. Silently ignoring unknown options
>is correct, per rfc1122 page 85:
>         4.2.2.5  TCP Options: RFC-793 Section 3.1
>            A TCP MUST be able to receive a TCP option in any segment.
>            A TCP MUST ignore without error any TCP option it does not
>            implement, assuming that the option has a length field (all
>            TCP options defined in the future will have length fields).
>            TCP MUST be prepared to handle an illegal option length
>            (e.g., zero) without crashing; a suggested procedure is to
>            reset the connection and log the reason.
(snip)
>>         should it [1] raise error on fatal failure and cause tcp code to
>>         drop the tcp segment completely?  or the current behavior [2] is
>>         right? ([2] ignore tcp option part, while accepting tcp segment)
>[] mine.
>or should it [3] reset the connection? I would say that [1] is wrong,
>and it is between [2] and [3]. Given the lack of a convincing rationale
>for [3], I think we should go with [2].
>Perhaps a tcp-impl discussion should be initiated.

	i was not clear enough, there can be couple of interpretation for
	"invalid option", and there can be couple of possible behaviors.
	1. length field out-of-bound (like optlen < 2, or optlen > cnt)
		- ignore all subsequent options (as option part looks broken)
		  and accept the segment
		- drop the segment, or
		- reset the connection (rfc suggests this, it seems)
	2. length field unexpected for known option type
		- skip over the option and look at the next one
		- ignore all subsequent options, and accept the segment
		- drop the segment, or
		- reset the connection
	3. option unexpected for this situation (like TCPOPT_WINDOW on non-SYN)
		- skip over the option and look at the next one
		- ignore all subsequent options, and accept the segment
		- drop the segment, or
		- reset the connection
	4. unknown option type
		- ignore the option and skip to the next one, as indicated
		  in the above RFC

>>       - tcp_dooptions try to skip over options with invalid length and
>>         continue to the next option.  it looks a bit optimistic.
>Does it? My reading is that it it "break"s within the for loop,
>which terminates the for loop and terminates option processing.

	the current behavior differs depends on how invalid it is.
	1. length field out-of-bound (like optlen < 2, or optlen > cnt)
		ignore subsequent options, accept the segment by "break"
	2. length field unexpected for known option type
		skip over the option and proceed to the next one, by "continue".
	3. unexpected option (like TCPOPT_WINDOW on non-SYN)
		skip over the option and proceed to the next one, by "continue".
	4. unknown option type
		ignore the option and skip to the next one

itojun