linux/net/dccp/input.c, branch v2.6.19

[DCCP]: Update documentation references.

2006-10-24T23:17:51Z

Updates the references to spec documents throughout the code, taking into account that * the DCCP, CCID 2, and CCID 3 drafts all became RFCs in March this year * RFC 1063 was obsoleted by RFC 1191 * draft-ietf-tcpimpl-pmtud-0x.txt was published as an Informational RFC, RFC 2923 on 2000-09-22. All references verified. Signed-off-by: Gerrit Renker Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller

Remove obsolete #include

2006-06-30T17:25:36Z

Signed-off-by: Jörn Engel Signed-off-by: Adrian Bunk

[DCCP] minisock: Rename struct dccp_options to struct dccp_minisock

2006-03-21T06:50:58Z

This will later be included in struct dccp_request_sock so that we can have per connection feature negotiation state while in the 3way handshake, when we clone the DCCP_ROLE_LISTEN socket (in dccp_create_openreq_child) we'll just copy this state from dreq_minisock to dccps_minisock. Also the feature negotiation and option parsing code will mostly touch dccps_minisock, which will simplify some stuff. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller

[DCCP]: Uninline some functions

2006-03-21T05:58:56Z

Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller

[DCCP]: Generalize dccp_v4_send_reset

2006-03-21T03:25:24Z

Renaming it to dccp_send_reset and moving it from the ipv4 specific code to the core dccp code. This fixes some bugs in IPV6 where timers would send v4 resets, etc. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller

[DCCP] CCID: Improve CCID infrastructure

2006-03-21T03:21:44Z

1. No need for ->ccid_init nor ->ccid_exit, this is what module_{init,exit} does and anynways neither ccid2 nor ccid3 were using it. 2. Rename struct ccid to struct ccid_operations and introduce struct ccid with a pointer to ccid_operations and rigth after it the rx or tx private state. 3. Remove the pointer to the state of the half connections from struct dccp_sock, now its derived thru ccid_priv() from the ccid pointer. Now we also can implement the setsockopt for changing the CCID easily as no ccid init routines can affect struct dccp_sock in any way that prevents other CCIDs from working if a CCID switch operation is asked by apps. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller

[DCCP]: Initial feature negotiation implementation

2006-03-21T01:43:56Z

Still needs more work, but boots and doesn't crashes, even does some negotiation! 18:38:52.174934 127.0.0.1.43458 > 127.0.0.1.5001: request 18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response 18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001: :-) Signed-off-by: Andrea Bittau Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller

[DCCP]: Notify CCID only after ACK vectors have been processed.

2006-01-03T22:26:15Z

The CCID should be notified of packet reception only when a packet is valid. Therefore, the ACK vector needs to be processed before notifying the CCID. Also, the CCID might need information provided by the ACK vector. Signed-off-by: Andrea Bittau Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller

[DCCP]: Send an ACK vector when ACKing a response packet

2006-01-03T22:25:49Z

If ACK vectors are used, each packet with an ACK should contain an ACK vector. The only exception currently is response packets. It probably is not a good idea to store ACK vector state before the connection is completed (to help protect from syn floods). Signed-off-by: Andrea Bittau Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller

[DCCP]: Do not process a packet twice when it's not in state DCCP_OPEN.

2006-01-03T22:25:17Z

When packets are received, the connection is either in DCCP_OPEN [fast-path] or it isn't. If it's not [e.g. DCCP_PARTOPEN] upper layers will perform sanity checks and parse options. If it is in DCCP_OPEN, dccp_rcv_established() will do it. It is important not to re-parse options in dccp_rcv_established() when it is not called from the fast-path. Else, fore example, the ack vector will be added twice and the CCID will see the packet twice. The solution is to always enfore sanity checks from the upper layers. When packets arrive in the fast-path, sanity checks will be performed before calling dccp_rcv_established(). Note(acme): I rewrote the patch to achieve the same result but keeping dccp_rcv_established with the previous semantics and having it split into __dccp_rcv_established, that doesn't does do any sanity check, code in state != DCCP_OPEN use this lighter version as they already do the sanity checks. Signed-off-by: Andrea Bittau Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller