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