Quoting Ian McDonald:
| On 9/27/06, Vladimir M <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
