On 16:42, Gerrit Renker wrote:
> I would much rather hunt down this bug than revert this patch, since reverting it
> means that almost twice the work is done per each packet and truly bidirectional
> connections are not currently supported.
Agreed. Let's try to find the bug.
> With initial tests here I could not reproduce the bug and had difficulties
> since I have not all required libraries for paraslash.
You only need libssl-dev to reproduce the bug. All the other libraries
are optional and configure should detect what is installed on your
system.
> 1. I see you are using loopback (127.0.0.1) where packets are routed back
> internally: does the bug persist when CCID2 sender and CCID2 receiver
> are on different hosts?
Not so easy to find out because I only have one machine and no
internet at home, and no kernel with dccp support at work. I'll see
what I can do.
> 2. This is using CCID2, which has not been maintained for a while. Can
> you please try CCID 3 also, e.g. by using the following sysctls:
>
> sysctl -w net.dccp.default.rx_ccid=3
> sysctl -w net.dccp.default.tx_ccid=3
> sysctl -w net.dccp.default.tx_qlen=5
> sysctl -w net.dccp.default.seq_window=100
> sysctl -w net.dccp.default.send_ackvec=0
Will do this today in the evening and report again tomorrow.
> 3. Caveat: `Server' listens, `Client' connects. I could not build the paraslash app
> due to missing libraries, but found that dccp_recv_open calls connect in dccp_recv.c
> while dccp_open() in dccp_send.c calls listen(). It seems that the roles are reversed,
> is it possible to swap this in the application and does the problem persist?
Well, that's possible, but IMHO does not make much sense: The server
app waits for incoming connections (not neccessary only dccp) and
responds by sending the audio stream to the client. That's how it's
supposed to be, no?
> The BUG is caused via the following chain:
>
> 1. dccp_write_xmit(sk, 0) (due to !block)
> 1. dccp_sendmsg
> 2. ccid2_hc_tx_send_packet -> with hctx->ccid2hctx_pipe >= hctx->ccid2hctx_cwnd
> (see above, pipe=cwnd=1) ==> returns 1
> 3. in dccp_write_xmit(sk, 0):
> if (!block) { /* this is true here */
> sk_reset_timer(sk, &dp->dccps_xmit_timer,
> msecs_to_jiffies(err)+jiffies)
> ==> BUG()
> | <7>dccp_set_state: listen(c1580030) LISTEN -> CLOSED
> This may be a clue: this socket has not gone past listen state (i.e. not entered server)
Yes, the bug happens in para_server just at the moment the first client
connects. No data is transfered to the client. I'll look into the kernel
dccp code a bit this evening as well.
Thanks for your help
Andre
--
The only person who always got his work done by Friday was Robinson Crusoe
Attachment:
signature.asc
Description: Digital signature
