Re: [PATCH 1/6]: Don't process Ack twice in Respond state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/28/07, Gerrit Renker <gerrit@xxxxxxxxxxxxxx> wrote:
> --------> Note: for the record only, patch has been merged with
>           [DCCP]: Integration of dynamic feature activation - part 3 (client side)
>
> [DCCP]: Don't process Ack twice in Respond state
>
> This fixes a bug in the feature negotiation code: the problem is that the Ack which leads
> from RESPOND to OPEN state is processed twice, causing the following problems:
>
>  * options are parsed on request_sock in dccp_check_req and on the child socket in
>    dccp_rcv_state_process (called via dccp_child_process);
>  * redundant sequence-validity test (the one in dccp_check_req is more stringent);
>  * input is delivered to CCIDs in RESPOND state, while it should only be delivered in
>    OPEN/PARTOPEN state;
>  * since Ack Vectors (if enabled) are already loaded at that time, Ack vector accounting
>    counts the Ack which completes the initial handshake, which is confusing, since it
>    should really start in state OPEN/PARTOPEN.
>
> Note: The only states that the CCIDs/AckVecs will get input now in dccp_rcv_state_process
>       are the closing states - do we really need to feed the input to CCIDs/AckVec when
>       the connection is closing anyway???
>
> Signed-off-by: Gerrit Renker <gerrit@xxxxxxxxxxxxxx>

Acked-by: Ian McDonald <ian.mcdonald@xxxxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [IETF DCCP]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux