Bugs item #1932587, was opened at 2008-04-02 22:09 Message generated for change (Comment added) made by bagder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=703942&aid=1932587&group_id=125852
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Out of Date Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Daniel Stenberg (bagder) Summary: Unable to re-exchange keys with openssh Initial Comment: When using sftp client to upload a very large file (mine is roughly 3 GB) libssh goes into an infinite loop. I've had this occur using several sshd servers including openssh. The crash is due to a stack overflow. This is the constant backtrace: ... fullpacket libssh2_packet_read libssh2_packet_require_ex libssh2_kex_method_diffie_hellman_groupGP_sha1_key_exchange libssh2_kex_method_diffie_hellman_group14_sha1_key_exchange libssh2_kex_exchange libssh2_packet_add fullpacket It's easier to repro this if you tweak openssh sshd.c to cause key re-exchange sooner. Currently the settings are after ~1 GB of data xfered. The reccomended settings in the RFC.(http://www.ietf.org/rfc/rfc4253.txt) Any help would be greatly appreciated. Thanks, Mike ---------------------------------------------------------------------- >Comment By: Daniel Stenberg (bagder) Date: 2009-05-07 18:51 Message: Does this still happen? Do (any of) you have a proper patch for this problem if so? ---------------------------------------------------------------------- Comment By: Mike Giancola (mikegiancola99) Date: 2008-04-08 17:00 Message: Logged In: YES user_id=2052992 Originator: NO in packet.c add_packet method, line ~912 in the conditional, if ((data[0] == SSH_MSG_KEXINIT && !(session->state & LIBSSH2_STATE_EXCHANGING_KEYS)) || (session->packAdd_state == libssh2_NB_state_sent2)) { if (session->packAdd_state == libssh2_NB_state_sent1) { why do we need the || (session->packAdd_state == libssh2_NB_state_sent2) check? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-04-07 21:52 Message: Logged In: NO I have a "fix" in place, looking to clean it up now. Changes made (both in packet.c): In the libssh2_packet_add method, there is a gate around the call to libssh2_kex_exchange to check if we are in the process of exchanging keys. However, the OR statement causes this call to be executed even if we're in the process of exchanging keys. This is why we get stuck in the infinite loop. My current hack is to put a gate around the call to libssh2_kex_exchange make sure we only do this once. I'm attempting to rework the logic in the if statement to accomplish the same goal, only call this method once if we are exchanging keys. Additionally, in the libssh2_packet_add if we are in the idle state, we clear out the packAdd_key_state object in the session. This holds the components we need to complete the new key exchange. My current hack is to put a gate around this call to only empty it if we are not exchanging keys. With these 2 hacks in place, i'm able to transfer over 4 GB of data. I'm attempting to find a better solution now. ---------------------------------------------------------------------- Comment By: Mike Giancola (mikegiancola99) Date: 2008-04-03 15:11 Message: Logged In: YES user_id=2052992 Originator: NO With trace turned on, it appears we're waiting on packet w/ id 31 (SSH_MSG_KEXDH_REPLY). Inside transport.c ::libssh2_packet_read method, i believe we are parsing either the 31 id'ed packet incorrectly, or the previous. The encrypted flag is true, but the numdecrypt variable is set to a negative #. (the p->total_num equals the p->data_num. This causes the value of numdecrypt to be equal to -skip. Since numdecrypt is < 0 and numbytes is equal to 0, the readidx and wptr are never incremented. Additionally, since total_num and data_num are the same, remainpack == 0, so we loop again into full packet. We also never do a recv again to wait on another packet. ---------------------------------------------------------------------- Comment By: Mike Giancola (mikegiancola99) Date: 2008-04-03 15:05 Message: Logged In: YES user_id=2052992 Originator: NO I changed the sftp.c file in the example/simple/sftp.c to upload a file instead of receive a file. I believe receive will also have same crash: /* ********************************************* */ /* Send a file instead of receive */ /* ********************************************* */ LIBSSH2_SFTP_HANDLE* sftp_dir = 0; sftp_dir = libssh2_sftp_opendir(sftp_session, "/"); sftp_handle = libssh2_sftp_open(sftp_session, "bigfile.data", LIBSSH2_FXF_WRITE|LIBSSH2_FXF_CREAT|LIBSSH2_FXF_TRUNC, LIBSSH2_SFTP_S_IRUSR|LIBSSH2_SFTP_S_IWUSR| LIBSSH2_SFTP_S_IRGRP|LIBSSH2_SFTP_S_IROTH); /* Request a file via SFTP */ // sftp_handle = // libssh2_sftp_open(sftp_session, sftppath, LIBSSH2_FXF_READ, 0); if (!sftp_handle) { printf ("mikeg big trouble 1\n"); fprintf(stderr, "Unable to open file with SFTP\n"); goto shutdown; } const char* inFile = "/home/mgiancola/test/bigfile.data"; FILE* filePtr = fopen(inFile, "rb"); if (!filePtr) { printf ("unable to open file \n"); return -1; } size_t nread = 0; size_t my_rc = 0; char mem[32768]; // 32k char* ptr = 0; nread = fread(mem, 1, sizeof(mem), filePtr); while (nread > 0) { ptr = mem; my_rc = libssh2_sftp_write(sftp_handle, ptr, nread); while ((my_rc > 0) && (nread > 0)) { ptr += rc; nread -= rc; if (nread > 0) my_rc = libssh2_sftp_write(sftp_handle, ptr, nread); } nread = fread(mem, 1, sizeof(mem), filePtr); } fclose (filePtr); /* ********************************************* */ /* End of send file */ /* ********************************************* */ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-04-02 22:45 Message: Logged In: NO I have a modified version of the simple/sftp.c that exhibits this seg fault. I can send to anyone for help. It appears that the failure is around the SSH_MSG_KEXDH_REPLY message. I see the SSH_MSG_KEXINIT message and i see the client / server agreement on kex method, host key etc, but then we crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=703942&aid=1932587&group_id=125852 ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ libssh2-devel mailing list libssh2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libssh2-devel
