From: Todd R. E. <to...@te...> - 2003-05-21 16:12:01
|
I'm having an occasional, very minor, problem I haven't seen since 1.1 days. I run rdesktop and the window pops, draws a blue background, and then rdesktop exits with ERROR: recv: Connection reset by peer The problem went away under 1.2; I don't remember ever seeing it, even once. The last few weeks I've been running the CVS version using -5 (RDP5) and get that once in a while. The aborts will happen from 0 to 3 times before I get connected successfully. Once I'm connected, it's fine and rock solid. Normally, every time it happens once or twice and I fire up tcpdump, it works the very next time. (Figures!) This morning, I managed to catch one. There are a total of 22 packets exchanged from start to finish, and it ends with the server sending an RST. This is a "tcpdump -r" of the capture. I have the contents, too, if anyone is interested. 09:58:33.564469 client.52987 > server.3389: S 2494539211:2494539211(0) win 5840 <mss 1460,sackOK,timestamp 596449101 0,nop,wscale 0> (DF) 09:58:33.565081 server.3389 > client.52987: S 3001015815:3001015815(0) ack 2494539212 win 64240 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF) 0.565152 client.52987 > server.3389: . ack 1 win 5840 <nop,nop,timestamp 596449102 0> (DF) 0.565351 client.52987 > server.3389: P 1:44(43) ack 1 win 5840 <nop,nop,timestamp 596449102 0> (DF) 0.566805 server.3389 > client.52987: P 1:12(11) ack 44 win 64197 <nop,nop,timestamp 491445 596449102> (DF) 0.566855 client.52987 > server.3389: . ack 12 win 5840 <nop,nop,timestamp 596449104 491445> (DF) 0.567009 client.52987 > server.3389: P 44:450(406) ack 12 win 5840 <nop,nop,timestamp 596449104 491445> (DF) 0.571945 server.3389 > client.52987: P 12:1439(1427) ack 450 win 63791 <nop,nop,timestamp 491445 596449104> (DF) 0.572704 client.52987 > server.3389: P 450:462(12) ack 1439 win 8562 <nop,nop,timestamp 596449109 491445> (DF) 0.572848 client.52987 > server.3389: P 462:470(8) ack 1439 win 8562 <nop,nop,timestamp 596449110 491445> (DF) 0.573323 server.3389 > client.52987: . ack 470 win 63771 <nop,nop,timestamp 491445 596449109> (DF) 0.573400 server.3389 > client.52987: P 1439:1450(11) ack 470 win 63771 <nop,nop,timestamp 491445 596449109> (DF) 0.573507 client.52987 > server.3389: P 470:482(12) ack 1450 win 8562 <nop,nop,timestamp 596449110 491445> (DF) 0.574131 server.3389 > client.52987: P 1450:1465(15) ack 482 win 63759 <nop,nop,timestamp 491445 596449110> (DF) 0.574198 client.52987 > server.3389: P 482:494(12) ack 1465 win 8562 <nop,nop,timestamp 596449111 491445> (DF) 0.574726 server.3389 > client.52987: P 1465:1480(15) ack 494 win 63747 <nop,nop,timestamp 491445 596449111> (DF) 0.574791 client.52987 > server.3389: P 494:506(12) ack 1480 win 8562 <nop,nop,timestamp 596449112 491445> (DF) 0.575263 server.3389 > client.52987: P 1480:1495(15) ack 506 win 63735 <nop,nop,timestamp 491445 596449112> (DF) 0.575330 client.52987 > server.3389: P 506:601(95) ack 1495 win 8562 <nop,nop,timestamp 596449112 491445> (DF) 0.575538 client.52987 > server.3389: P 601:952(351) ack 1495 win 8562 <nop,nop,timestamp 596449112 491445> (DF) 0.576360 server.3389 > client.52987: . ack 952 win 63289 <nop,nop,timestamp 491445 596449112> (DF) 0.577821 server.3389 > client.52987: R 3001017310:3001017310(0) win 0 (DF) Todd |
From: Blue B. <Blu...@th...> - 2003-05-21 17:02:49
|
Todd R. Eigenschink wrote: > I'm having an occasional, very minor, problem I haven't seen since 1.1 > days. I run rdesktop and the window pops, draws a blue background, > and then rdesktop exits with > > ERROR: recv: Connection reset by peer <snip> > This is a "tcpdump -r" of the capture. I have the contents, too, if > anyone is interested. <snip> > 0.577821 server.3389 > client.52987: R 3001017310:3001017310(0) win 0 (DF) About all I can tell from the TCP level is that the server reset the TCP connection. I can't tell why it would do so. You might try compiling rdesktop in debug mode, and capturing all the output until the problem occurs. BB |
From: Erik F. <for...@ce...> - 2003-05-22 08:49:41
|
"Todd R. Eigenschink" <to...@te...> writes: > The last few weeks I've been running the CVS version using -5 (RDP5) > and get that once in a while. The aborts will happen from 0 to 3 > times before I get connected successfully. Once I'm connected, it's > fine and rock solid. Yup. I've seen this problem as well. The server says something about a error in the "DATA ENCRYPTION COMPONENT" in the event log, do you get that as well? It's a quite strange problem, especially since it's not occuring every time, but instead as you say, from 0 to 3 times before a good connection. Hmm.. Compared to how the MS client sends the client random I've coded some differences - where the MS client sends only zeros, I send some random data with the intention to make known-plaintext-attacks harder. This seemed to work a few months ago, and I think I tested with and without zeros. However, patching it not to send randomness but zeros seems to solve the problem with refused connections. *Writing a evil shellscript* Hmm.. The CVS-version (Revision 1.26 of secure.c) fails in 287 of 882 attempts, but the version that pads with zeros instead of randomness fails in 0 of 876 attempts. I guess we can safely come to the conclusion that the version with zeros is much better.. :-) I've updated the CVS (now to Revision 1.27 of secure.c). Please test and report back your results, preferably both after preliminary tests and after a week or so. Regards, \EF -- Erik Forsberg Telephone: +46-13-21 46 00 Cendio Systems Web: http://www.cendio.se |
From: Todd R. E. <to...@te...> - 2003-05-22 12:33:27
|
Erik Forsberg writes: >Yup. I've seen this problem as well. The server says something about a >error in the "DATA ENCRYPTION COMPONENT" in the event log, do you get >that as well? I hadn't ever noticed before, but I just went looking: The RDP protocol component "DATA ENCRYPTION" detected an error in the protocol stream and has disconnected the client. >some differences - where the MS client sends only zeros, I send some >random data with the intention to make known-plaintext-attacks >harder. This seemed to work a few months ago, and I think I tested >with and without zeros. However, patching it not to send randomness >but zeros seems to solve the problem with refused connections. It's probably OK, except when you get some certain value(s) in some certain place(s) in the padding, and then it blows up. I just refreshed from CVS and I'll let you know what happens. Todd |