All of lore.kernel.org
 help / color / mirror / Atom feed
* Sequence numbers in Response packets (Linux 2.6.17)
@ 2006-09-27 11:56 Vladimir M
  2006-09-27 21:33 ` Ian McDonald
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Vladimir M @ 2006-09-27 11:56 UTC (permalink / raw)
  To: dccp


Hi,

While doing some tresting, I've noticed a funny behaviour of DCCP implementation in 2.6 kernel. From Ethereal capture seems that retransmitted response packets do not increment the sequence number. Is it a correct behaviour? If yes, then why is it done like this, since protocol's RFC instructs to increment on every outgoing packet. 

B.R.
Vladimir.

P.S. Don't know, it it has been already discussed on the list or not, or even patched. I have original DCCP version from 2.6.17 FC5, but havnt found anything related in archives of this list

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Sequence numbers in Response packets (Linux 2.6.17)
  2006-09-27 11:56 Sequence numbers in Response packets (Linux 2.6.17) Vladimir M
@ 2006-09-27 21:33 ` Ian McDonald
  2006-11-09 11:23 ` Gerrit Renker
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Ian McDonald @ 2006-09-27 21:33 UTC (permalink / raw)
  To: dccp

On 9/27/06, Vladimir M <vladivm@mail.ru> wrote:
>
> Hi,
>
> While doing some tresting, I've noticed a funny behaviour of DCCP implementation in 2.6 kernel. From Ethereal capture seems that retransmitted response packets do not increment the sequence number. Is it a correct behaviour? If yes, then why is it done like this, since protocol's RFC instructs to increment on every outgoing packet.
>
> B.R.
> Vladimir.
>
> P.S. Don't know, it it has been already discussed on the list or not, or even patched. I have original DCCP version from 2.6.17 FC5, but havnt found anything related in archives of this list

Vladimir,

You are correct in saying this and it hasn't been fixed yet as of the
latest code. The reason for this is that we just clone the skb and
haven't updated the header. Feel free to get in and fix if you want!

I have added this to the DCCP to do list -
http://linux-net.osdl.org/index.php/TODO#DCCP

Thanks,

Ian
-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Sequence numbers in Response packets (Linux 2.6.17)
  2006-09-27 11:56 Sequence numbers in Response packets (Linux 2.6.17) Vladimir M
  2006-09-27 21:33 ` Ian McDonald
@ 2006-11-09 11:23 ` Gerrit Renker
  2006-11-09 19:45 ` Ian McDonald
  2006-11-09 21:55 ` Arnaldo Carvalho de Melo
  3 siblings, 0 replies; 5+ messages in thread
From: Gerrit Renker @ 2006-11-09 11:23 UTC (permalink / raw)
  To: dccp


Quoting Ian McDonald:
|  On 9/27/06, Vladimir M <vladivm@mail.ru> wrote:
|  >
|  > Hi,
|  >
|  > While doing some tresting, I've noticed a funny behaviour of DCCP implementation in 2.6 kernel. From Ethereal capture seems that retransmitted response packets do not increment the sequence number. Is it a correct behaviour? If yes, then why is it done like this, since protocol's RFC instructs to increment on every outgoing packet.
|  >
|  > B.R.
|  > Vladimir.
|  >
|  > P.S. Don't know, it it has been already discussed on the list or not, or even patched. I have original DCCP version from 2.6.17 FC5, but havnt found anything related in archives of this list
|  
|  Vladimir,
|  
|  You are correct in saying this and it hasn't been fixed yet as of the
|  latest code. The reason for this is that we just clone the skb and
|  haven't updated the header. Feel free to get in and fix if you want!
|  
|  I have added this to the DCCP to do list -
|  http://linux-net.osdl.org/index.php/TODO#DCCP

Alas, there is some confusion here. 

The problem is not in cloning the skb, this works fine. 

The only identifiable problem that I can find in this regard sits in a different corner:
DCCP-Responses triggered both by receipt of a (retransmitted) DCCP-Request and, at a later
timer, through the dccp_response_timer(); details are also below.


1) Retransmission works!
------------------------
The only retransmittable packets are:
 *  Requests in client-REQUEST  state (sec. 8.1.1)
 *  Acks     in client-PARTOPEN state (sec. 8.1.5)
 *  CloseReq in server-CLOSEREQ state (sec. 8.3)
 *  Close    in   node-CLOSING  state (sec. 8.3)    

And these are taken care of by the dccp_retransmit_skb(), triggered via dccp_retransmit_timer().
That one in turn calls dccp_transmit_skb(), which has the lines

		dccp_inc_seqno(&dp->dccps_gss);
		/* ... */
		dccp_hdr_set_seq(dh, dp->dccps_gss);

This means that sent sequence numbers on retransmittable packets are increased: so this works.


2) Responses to retransmitted requests also work
------------------------------------------------
All responses that are triggered by incoming, retransmitted requests also correctly have their
sequence number incremented. 

This can be confirmed using the following scenario:
	* host A has iptables rule to drop all incoming DCCP (-p 33) packets
	* host B has a listening DCCP application and answers the requests from A
	* host A never sees any responses to its responses and retransmits until it gives up

Since retransmitted Requests work due to (1), packets enter dccp_check_req(), which
will identify `Retransmitted REQUEST' in syslog. And it will increment the sequence number:
		
	dccp_set_seqno(&dreq->dreq_iss, dreq->dreq_iss + 1);

Hence triggered Responses also work.


3) Interaction with timer
-------------------------
Since (1,2) both work, I think what Vladimir referred to was a sequence of two Responses sent
in reply to a single Request. These can indeed be observed, but have a variable difference
of time (using the test setup of (2)). Of these the first is the genuine Response, and the
second one is triggered by a timeout in dccp_response_timer(), which calls dccp_v{4,6}_send_response()
via the indirection of inet_csk_reqsk_queue_prune(). And in this case -- and this case only --
the response packets have identical sequence numbers.
Although this is a relatively minor bug, I believe it would be better to stick by the DCCP rule
that `each outgoing packet has its sequence number incremented' and will send a patch.

Ian, I will remove this ToDo from the list, ok?

Thanks to Vladimir for pointing this out; but it would in future be much more helpful to
have some real traces to work on - otherwise it really is hard to figure out the causes. 

Gerrit


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Sequence numbers in Response packets (Linux 2.6.17)
  2006-09-27 11:56 Sequence numbers in Response packets (Linux 2.6.17) Vladimir M
  2006-09-27 21:33 ` Ian McDonald
  2006-11-09 11:23 ` Gerrit Renker
@ 2006-11-09 19:45 ` Ian McDonald
  2006-11-09 21:55 ` Arnaldo Carvalho de Melo
  3 siblings, 0 replies; 5+ messages in thread
From: Ian McDonald @ 2006-11-09 19:45 UTC (permalink / raw)
  To: dccp

> Although this is a relatively minor bug, I believe it would be better to stick by the DCCP rule
> that `each outgoing packet has its sequence number incremented' and will send a patch.
>
> Ian, I will remove this ToDo from the list, ok?
>
> Thanks to Vladimir for pointing this out; but it would in future be much more helpful to
> have some real traces to work on - otherwise it really is hard to figure out the causes.
>
> Gerrit
>
>
Thanks Gerrit for doing the legwork on this one. As you say the bug is
more minor than first identified. I'm happy for you to update the ToDo
list with this info or remove once you've sent your patch.

You're doing well to work through these. Just wish I had more time to help!

Ian
-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Sequence numbers in Response packets (Linux 2.6.17)
  2006-09-27 11:56 Sequence numbers in Response packets (Linux 2.6.17) Vladimir M
                   ` (2 preceding siblings ...)
  2006-11-09 19:45 ` Ian McDonald
@ 2006-11-09 21:55 ` Arnaldo Carvalho de Melo
  3 siblings, 0 replies; 5+ messages in thread
From: Arnaldo Carvalho de Melo @ 2006-11-09 21:55 UTC (permalink / raw)
  To: dccp

On 11/9/06, Ian McDonald <ian.mcdonald@jandi.co.nz> wrote:
> > Although this is a relatively minor bug, I believe it would be better to stick by the DCCP rule
> > that `each outgoing packet has its sequence number incremented' and will send a patch.
> >
> > Ian, I will remove this ToDo from the list, ok?
> >
> > Thanks to Vladimir for pointing this out; but it would in future be much more helpful to
> > have some real traces to work on - otherwise it really is hard to figure out the causes.
> >
> > Gerrit
> >
> >
> Thanks Gerrit for doing the legwork on this one. As you say the bug is
> more minor than first identified. I'm happy for you to update the ToDo
> list with this info or remove once you've sent your patch.
>
> You're doing well to work through these. Just wish I had more time to help!

Even not being a dilligent maintainer in the last months, I'm very,
very happy indeed with the community slowing being formed around the
Linux DCCP codebase, I'll try not to miss the 2.6.20 merge window to
get Gerrit patch queue merged after reviewing it.

Thanks everybody for validating what is there and for working on
fixing and implementing new stuff.

- Arnaldo

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2006-11-09 21:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-27 11:56 Sequence numbers in Response packets (Linux 2.6.17) Vladimir M
2006-09-27 21:33 ` Ian McDonald
2006-11-09 11:23 ` Gerrit Renker
2006-11-09 19:45 ` Ian McDonald
2006-11-09 21:55 ` Arnaldo Carvalho de Melo

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.