2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-20 00:23:43 -03:00
|
|
|
|
|
|
|
|
|
2006-08-26 19:01:30 -07:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-24 10:46:58 -02:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-18 00:17:51 -07:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
[DCCP]: Initial feature negotiation implementation
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 <change_l ack_ratio 2, change_r ccid 2, change_l ccid 2>
18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response <nop, nop, change_l ack_ratio 2, confirm_r ccid 2 2, confirm_l ccid 2 2, confirm_r ack_ratio 2>
18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001: <nop, confirm_r ack_ratio 2, ack_vector0 0x00, elapsed_time 212>
:-)
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 17:43:56 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-11-23 16:07:53 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-11-23 16:07:53 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-11-23 16:07:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-11-23 16:07:53 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-11-23 16:07:53 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-11-23 16:07:53 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-13 12:29:24 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-13 20:34:54 -03:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
2008-11-25 16:57:30 -08:00
|
|
|
|
2005-09-09 02:32:01 -03:00
|
|
|
|
2007-10-24 10:46:58 -02:00
|
|
|
|
[DCCP]: Initial feature negotiation implementation
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 <change_l ack_ratio 2, change_r ccid 2, change_l ccid 2>
18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response <nop, nop, change_l ack_ratio 2, confirm_r ccid 2 2, confirm_l ccid 2 2, confirm_r ack_ratio 2>
18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001: <nop, confirm_r ack_ratio 2, ack_vector0 0x00, elapsed_time 212>
:-)
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 17:43:56 -08:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 22:36:01 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-23 13:28:27 +02:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
2008-08-23 13:28:27 +02:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-23 13:28:27 +02:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
2007-12-13 12:29:24 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-11 11:19:09 +01:00
|
|
|
|
2007-12-13 12:29:24 -02:00
|
|
|
|
2010-09-19 20:08:00 +02:00
|
|
|
|
2008-06-11 11:19:09 +01:00
|
|
|
|
2007-12-13 12:29:24 -02:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[DCCP]: Initial feature negotiation implementation
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 <change_l ack_ratio 2, change_r ccid 2, change_l ccid 2>
18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response <nop, nop, change_l ack_ratio 2, confirm_r ccid 2 2, confirm_l ccid 2 2, confirm_r ack_ratio 2>
18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001: <nop, confirm_r ack_ratio 2, ack_vector0 0x00, elapsed_time 212>
:-)
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 17:43:56 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 22:06:02 -08:00
|
|
|
|
|
|
|
|
|
[DCCP]: Initial feature negotiation implementation
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 <change_l ack_ratio 2, change_r ccid 2, change_l ccid 2>
18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response <nop, nop, change_l ack_ratio 2, confirm_r ccid 2 2, confirm_l ccid 2 2, confirm_r ack_ratio 2>
18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001: <nop, confirm_r ack_ratio 2, ack_vector0 0x00, elapsed_time 212>
:-)
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 17:43:56 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-07-13 11:51:40 +01:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-13 11:51:40 +01:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-12-01 23:33:18 -08:00
|
|
|
|
|
|
|
|
|
2007-12-13 12:48:19 -02:00
|
|
|
|
2011-05-06 03:27:18 +00:00
|
|
|
|
|
|
|
|
|
2008-12-01 23:32:35 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-09 13:27:22 +02:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 12:37:19 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-24 10:46:58 -02:00
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 12:37:19 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 12:37:19 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-14 12:57:34 -02:00
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 12:37:19 -02:00
|
|
|
|
2005-08-09 20:27:14 -07:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2010-10-11 20:41:13 +02:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
2005-08-20 00:23:43 -03:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
2007-10-24 10:46:58 -02:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2006-11-14 12:57:34 -02:00
|
|
|
|
2007-04-20 13:56:47 -07:00
|
|
|
|
2005-08-13 20:34:54 -03:00
|
|
|
|
2005-08-09 20:27:14 -07:00
|
|
|
|
|
|
|
|
|
2005-08-20 00:23:43 -03:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2007-10-24 10:46:58 -02:00
|
|
|
|
2005-08-20 00:23:43 -03:00
|
|
|
|
2007-10-24 10:46:58 -02:00
|
|
|
|
2007-04-20 13:56:47 -07:00
|
|
|
|
2005-09-09 02:32:01 -03:00
|
|
|
|
2007-04-20 13:56:47 -07:00
|
|
|
|
2005-09-09 02:32:01 -03:00
|
|
|
|
2007-10-24 10:46:58 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 02:32:01 -03:00
|
|
|
|
2007-10-04 14:44:01 -07:00
|
|
|
|
2007-04-20 13:56:47 -07:00
|
|
|
|
2005-09-09 02:32:01 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
2007-11-21 10:13:53 -02:00
|
|
|
|
|
|
|
|
|
2005-08-20 00:23:43 -03:00
|
|
|
|
2007-10-24 10:46:58 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-21 10:13:53 -02:00
|
|
|
|
2007-10-24 10:46:58 -02:00
|
|
|
|
|
|
|
|
|
2007-11-21 10:13:53 -02:00
|
|
|
|
|
|
|
|
|
2007-10-24 10:46:58 -02:00
|
|
|
|
2005-09-09 02:32:01 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-20 00:23:43 -03:00
|
|
|
|
2006-11-14 12:57:34 -02:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2010-09-19 20:08:00 +02:00
|
|
|
|
2005-08-13 20:34:54 -03:00
|
|
|
|
2010-09-19 20:06:50 +02:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
2010-11-14 17:26:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-19 20:08:00 +02:00
|
|
|
|
2005-08-13 20:34:54 -03:00
|
|
|
|
2010-09-19 20:06:50 +02:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-20 18:39:23 -02:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2007-02-09 23:24:38 +09:00
|
|
|
|
2007-12-13 12:29:24 -02:00
|
|
|
|
[DCCP]: Initial feature negotiation implementation
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 <change_l ack_ratio 2, change_r ccid 2, change_l ccid 2>
18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response <nop, nop, change_l ack_ratio 2, confirm_r ccid 2 2, confirm_l ccid 2 2, confirm_r ack_ratio 2>
18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001: <nop, confirm_r ack_ratio 2, ack_vector0 0x00, elapsed_time 212>
:-)
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 17:43:56 -08:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
2006-03-20 22:06:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-23 13:28:27 +02:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-01 23:32:35 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-23 13:28:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 21:25:11 -08:00
|
|
|
|
|
|
|
|
|
2008-11-23 16:07:53 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-11-23 16:07:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-13 11:51:40 +01:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-07-13 11:51:40 +01:00
|
|
|
|
|
|
|
|
|
2010-05-24 14:33:03 -07:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
2010-06-22 01:14:34 +00:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
2008-07-13 11:51:40 +01:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-18 20:45:29 -03:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
2010-10-05 04:24:09 +00:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2007-09-25 22:40:13 -07:00
|
|
|
|
2005-08-20 00:23:43 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-22 01:14:34 +00:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 12:37:19 -02:00
|
|
|
|
|
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2006-03-20 19:23:32 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 12:37:19 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 02:38:35 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[DCCP]: Initial feature negotiation implementation
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 <change_l ack_ratio 2, change_r ccid 2, change_l ccid 2>
18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response <nop, nop, change_l ack_ratio 2, confirm_r ccid 2 2, confirm_l ccid 2 2, confirm_r ack_ratio 2>
18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001: <nop, confirm_r ack_ratio 2, ack_vector0 0x00, elapsed_time 212>
:-)
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 17:43:56 -08:00
|
|
|
|
2005-08-20 00:23:43 -03:00
|
|
|
|
2006-03-20 19:23:32 -08:00
|
|
|
|
2005-08-20 00:23:43 -03:00
|
|
|
|
|
|
|
|
|
2006-03-20 19:23:32 -08:00
|
|
|
|
2005-08-20 00:23:43 -03:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
2010-11-10 21:21:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-14 17:25:46 +01:00
|
|
|
|
2010-11-10 21:21:35 +01:00
|
|
|
|
2010-11-10 21:21:02 +01:00
|
|
|
|
2010-11-10 21:21:35 +01:00
|
|
|
|
|
|
|
|
|
2010-11-10 21:21:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-14 17:25:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-10 21:21:02 +01:00
|
|
|
|
2010-11-14 17:25:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-10 21:21:02 +01:00
|
|
|
|
|
|
|
|
|
2010-11-10 21:21:35 +01:00
|
|
|
|
2010-11-10 21:21:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-14 17:25:46 +01:00
|
|
|
|
2010-11-10 21:21:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-23 16:09:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-23 16:10:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-10 10:55:09 +00:00
|
|
|
|
2008-11-23 16:10:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-04 07:30:19 +02:00
|
|
|
|
2008-11-23 16:10:23 -08:00
|
|
|
|
2008-09-04 07:30:19 +02:00
|
|
|
|
2008-11-23 16:10:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-04 07:30:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-23 16:10:23 -08:00
|
|
|
|
2011-12-19 13:56:45 +00:00
|
|
|
|
2008-11-23 16:10:23 -08:00
|
|
|
|
2008-09-09 13:27:22 +02:00
|
|
|
|
2008-11-23 16:10:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[DCCP]: Initial feature negotiation implementation
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 <change_l ack_ratio 2, change_r ccid 2, change_l ccid 2>
18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response <nop, nop, change_l ack_ratio 2, confirm_r ccid 2 2, confirm_l ccid 2 2, confirm_r ack_ratio 2>
18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001: <nop, confirm_r ack_ratio 2, ack_vector0 0x00, elapsed_time 212>
:-)
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 17:43:56 -08:00
|
|
|
|
2008-11-23 16:10:23 -08:00
|
|
|
|
[DCCP]: Initial feature negotiation implementation
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 <change_l ack_ratio 2, change_r ccid 2, change_l ccid 2>
18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response <nop, nop, change_l ack_ratio 2, confirm_r ccid 2 2, confirm_l ccid 2 2, confirm_r ack_ratio 2>
18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001: <nop, confirm_r ack_ratio 2, ack_vector0 0x00, elapsed_time 212>
:-)
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 17:43:56 -08:00
|
|
|
|
|
|
|
|
|
2008-11-23 16:10:23 -08:00
|
|
|
|
|
|
|
|
|
[DCCP]: Initial feature negotiation implementation
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 <change_l ack_ratio 2, change_r ccid 2, change_l ccid 2>
18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response <nop, nop, change_l ack_ratio 2, confirm_r ccid 2 2, confirm_l ccid 2 2, confirm_r ack_ratio 2>
18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001: <nop, confirm_r ack_ratio 2, ack_vector0 0x00, elapsed_time 212>
:-)
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 17:43:56 -08:00
|
|
|
|
|
|
|
|
|
2008-09-09 13:27:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-13 12:38:11 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-08 01:18:37 -08:00
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-12-01 23:29:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
2008-12-01 23:29:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-22 01:14:35 +00:00
|
|
|
|
2008-12-01 23:29:30 -08:00
|
|
|
|
2010-06-22 01:14:34 +00:00
|
|
|
|
2008-12-01 23:29:30 -08:00
|
|
|
|
|
|
|
|
|
2010-11-10 21:21:35 +01:00
|
|
|
|
2008-12-01 23:29:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
2005-09-09 02:30:07 -03:00
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
|
|
|
|
|
2005-09-09 02:30:07 -03:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 12:37:19 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-13 12:38:11 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2007-12-13 12:38:11 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-12-01 23:29:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-22 01:14:35 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-13 12:38:11 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
2007-12-13 12:38:11 -02:00
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|