On Fri, 2003-01-17 at 14:15, Timo Sirainen wrote:
On Thu, 2003-01-16 at 03:31, james broermann wrote:
pine still doesn't want to work. It does detect that the server is using plain text passwords. I'll try the sniffer and see what turns up.
Whops, you're right. I've tested pine only with digest-md5 authentication before. Looks like my PLAIN authentication isn't working properly. Normally other clients just use LOGIN command which is different.
Patch is now available at http://dovecot.procontrol.fi/
On 17 Jan 2003 14:37:32 +0200 Timo Sirainen <tss@iki.fi> wrote:
On Fri, 2003-01-17 at 14:15, Timo Sirainen wrote:
On Thu, 2003-01-16 at 03:31, james broermann wrote:
pine still doesn't want to work. It does detect that the server is using plain text passwords. I'll try the sniffer and see what turns up.
Whops, you're right. I've tested pine only with digest-md5 authentication before. Looks like my PLAIN authentication isn't working properly. Normally other clients just use LOGIN command which is different.
Patch is now available at http://dovecot.procontrol.fi/
Hmm.
I'm running the debian package 0.99.7-2. If I turn off SSL, and allow plaintext, I can log in. If I turn SSL on (comment out ssl_diable = yes), then I can't. It was working in 0.99.6, I know.
Same situation using 0.99.7-1 alpha (it takes longer for alpha builds to make it into debian).
I can provide more information, as necessary. All that's logged is "disconnected for inactivity". Monitoring via tcpdump doesn't seem too useful, given that TLS is negotiated.
Amy!
Amelia A. Lewis amyzing {at} talsever.com Igne natura renovatur integra.
On Sat, 2003-01-18 at 19:01, Amelia A.Lewis wrote:
I'm running the debian package 0.99.7-2. If I turn off SSL, and allow plaintext, I can log in. If I turn SSL on (comment out ssl_diable = yes), then I can't. It was working in 0.99.6, I know.
If it was working in .6, I can't think of what could have broken. But here's a patch for more verbose logging if "auth_verbose = yes" in config file.
Dear Timo,
Thanks for the patch. It shows the connections, but auth never gets called.
I finally pulled my act together so that I could compile from source. So, I thought I would be a little more clear.
If I turn on ssl (comment out ssl_disable = yes, the default) and turn off plaintext (uncomment disable_plaintext_auth = yes), then immediately after SSL negotiation, my client hangs (I'm testing with mutt).
Eventually, I determined what's happening, to some degree. Alas, I've been programming in Java for five years, so I have trouble debugging a real programming language. However: in login/client.c, client_handle_input, the first part of the function checks for client->cmd_finished, and if so, clears client->cmd_tag and client->cmd_name. It then checks client->skip_line, and if true, calls client_skip_line. Adding debugging to client_skip_line (i_info with the contents of data) shows that, after the starttls command, client_skip_line discards the whole next command (in my case, a0002 CAPABILITY). The client is waiting for a response. The server is waiting for a command (having discarded one). login times out sixty seconds later, for inactivity.
There's where my skills prove inadequate, I'm afraid, because bypassing client_skip_line if the last command was STARTTLS doesn't seem to do any good; the server never sees the capability command. I'm between a rock and a hard place, it appears; if the server sees the command, it discards it and then times out, but if it doesn't, it times out anyway. *sigh*
No one else seems to be having this sort of problem, though. Is that because most folks are using TLS on the imaps port? Or have I got a misconfiguration that runs somehow deeper? I don't *think* I'm chasing a wild hare.
Sorry to be a bother.
Amy! On 21 Jan 2003 09:43:06 +0200 Timo Sirainen <tss@iki.fi> wrote:
On Sat, 2003-01-18 at 19:01, Amelia A.Lewis wrote:
I'm running the debian package 0.99.7-2. If I turn off SSL, and allow plaintext, I can log in. If I turn SSL on (comment out ssl_diable = yes), then I can't. It was working in 0.99.6, I know.
If it was working in .6, I can't think of what could have broken. But here's a patch for more verbose logging if "auth_verbose = yes" in config file.
-- Amelia A. Lewis amyzing {at} talsever.com There are two major products that came out of Berkeley: LSD and BSD Unix. We don't believe this to be a coincidence.
On Sun, 2003-02-02 at 08:28, Amelia A.Lewis wrote:
Eventually, I determined what's happening, to some degree. Alas, I've been programming in Java for five years, so I have trouble debugging a real programming language.
Java is real too :)
Adding debugging to client_skip_line (i_info with the contents of data) shows that, after the starttls command, client_skip_line discards the whole next command (in my case, a0002 CAPABILITY). The client is waiting for a response. The server is waiting for a command (having discarded one). login times out sixty seconds later, for inactivity.
Yes, so it seems.
No one else seems to be having this sort of problem, though. Is that because most folks are using TLS on the imaps port? Or have I got a misconfiguration that runs somehow deeper? I don't *think* I'm chasing a wild hare.
I've tested STARTTLS only with Evolution which I guess didn't mind about not getting a reply to next command.
Here's a patch, thanks for bug report :)
Dear Timo,
On 02 Feb 2003 09:15:19 +0200 Timo Sirainen <tss@iki.fi> wrote:
On Sun, 2003-02-02 at 08:28, Amelia A.Lewis wrote:
Adding debugging to client_skip_line (i_info with the contents of data) shows that, after the starttls command, client_skip_line discards the whole next command (in my case, a0002 CAPABILITY). The client is waiting for a response. The server is waiting for a command (having discarded one). login times out sixty seconds later, for inactivity.
Yes, so it seems.
No one else seems to be having this sort of problem, though. Is that because most folks are using TLS on the imaps port? Or have I got a misconfiguration that runs somehow deeper? I don't *think* I'm chasing a wild hare.
I've tested STARTTLS only with Evolution which I guess didn't mind about not getting a reply to next command.
Here's a patch, thanks for bug report :)
Thank you! Only it doesn't work. I don't quite know why, either (it's almost exactly what I tried, but skipping over the skip_line seems to mean that it can't find the tag to read). Which seems weird. Is it possible that client->parser->input != client->input? Such that client->parser->input still points at the original fd?
For whatever it might be worth, here's two runs of mutt, one without, and one with the patch. Most of the stuff occurs inside client_handle_input.
Feb 2 10:55:51 talifane imap-master: Dovecot starting up Feb 2 10:55:52 talifane imap-auth: Login process 6 connected Feb 2 10:55:52 talifane imap-auth: Login process 7 connected Feb 2 10:55:52 talifane imap-auth: Login process 8 connected Feb 2 10:55:52 talifane imap-auth: Login process 8 sent handshake: PID 9137 Feb 2 10:55:52 talifane imap-auth: Login process 7 sent handshake: PID 9138 Feb 2 10:55:52 talifane imap-auth: Login process 6 sent handshake: PID 9139 Feb 2 10:55:53 talifane imap-login: client_handle_input: cmd_tag is null Feb 2 10:55:53 talifane imap-login: client_handle_input: cmd_name is null Feb 2 10:55:53 talifane imap-login: client_handle_input: cmd_finished: cmd_tag: a0000 ; cmd_name: CAPABILITY Feb 2 10:55:53 talifane imap-login: Skipping line in data: Feb 2 10:55:53 talifane imap-login: Skipped 2 chars Feb 2 10:55:53 talifane imap-login: client_handle_input: cmd_tag is null Feb 2 10:55:53 talifane imap-login: client_handle_input: cmd_name is null Feb 2 10:55:53 talifane imap-login: gnutls ssl_proxy_new Feb 2 10:55:54 talifane imap-auth: Login process 9 connected Feb 2 10:55:54 talifane imap-auth: Login process 9 sent handshake: PID 9141 Feb 2 10:55:54 talifane imap-login: client_handle_input: cmd_finished: cmd_tag: a0001 ; cmd_name: STARTTLS Feb 2 10:55:54 talifane imap-login: Skipping line in data: a0002 CAPABILITY Feb 2 10:55:54 talifane imap-login: Skipped 18 chars Feb 2 10:55:54 talifane imap-login: client_handle_input: cmd_tag is null Feb 2 10:55:54 talifane imap-login: client_handle_input: can't fill cmd_tag (need more data) Feb 2 10:56:54 talifane imap-login: Disconnected: Inactivity [127.0.0.1] Feb 2 10:56:54 talifane imap-auth: Login process 8 disconnected
The next one is with the patch applied.
Feb 2 11:00:41 talifane imap-master: Dovecot starting up Feb 2 11:00:42 talifane imap-auth: Login process 6 connected Feb 2 11:00:42 talifane imap-auth: Login process 7 connected Feb 2 11:00:42 talifane imap-auth: Login process 8 connected Feb 2 11:00:42 talifane imap-auth: Login process 8 sent handshake: PID 9361 Feb 2 11:00:42 talifane imap-auth: Login process 7 sent handshake: PID 9362 Feb 2 11:00:42 talifane imap-auth: Login process 6 sent handshake: PID 9363 Feb 2 11:00:47 talifane imap-login: client_handle_input: cmd_tag is null Feb 2 11:00:47 talifane imap-login: client_handle_input: cmd_name is null Feb 2 11:00:47 talifane imap-login: client_handle_input: cmd_finished: cmd_tag: a0000 ; cmd_name: CAPABILITY Feb 2 11:00:47 talifane imap-login: Skipping line in data: Feb 2 11:00:47 talifane imap-login: Skipped 2 chars Feb 2 11:00:47 talifane imap-login: client_handle_input: cmd_tag is null Feb 2 11:00:47 talifane imap-login: client_handle_input: cmd_name is null Feb 2 11:00:47 talifane imap-login: gnutls ssl_proxy_new Feb 2 11:00:47 talifane imap-auth: Login process 9 connected Feb 2 11:00:47 talifane imap-auth: Login process 9 sent handshake: PID 9365 Feb 2 11:00:48 talifane imap-login: client_handle_input: cmd_finished: cmd_tag: a0001 ; cmd_name: STARTTLS Feb 2 11:00:48 talifane imap-login: client_handle_input: cmd_tag is null Feb 2 11:00:48 talifane imap-login: client_handle_input: can't fill cmd_tag (need more data) Feb 2 11:01:48 talifane imap-login: Disconnected: Inactivity [127.0.0.1] Feb 2 11:01:48 talifane imap-auth: Login process 8 disconnected
As you can see, the major difference is that it doesn't discard the command, but it still can't seem to see it (client_handle_input: can't fill cmd_tag (need more data) happens in just the place where "need more data" appears as a comment). Now, looking around, it appears that skip_line uses i_stream_get_data on client->input, while filling the tag calls imap_parser_read_word, which uses i_stream_get_data on parser->input. Does all the necessary information for the parser get reset in starttls?
Amy!
Amelia A. Lewis amyzing {at} talsever.com Early to bed and early to rise makes a man stupid and blind in the eyes.
Replying to myself, what fun. On Sun, 2 Feb 2003 11:06:39 -0500 "Amelia A.Lewis" <amyzing@talsever.com> wrote:
On 02 Feb 2003 09:15:19 +0200 Timo Sirainen <tss@iki.fi> wrote:
Here's a patch, thanks for bug report :)
Thank you! Only it doesn't work. I don't quite know why, either (it's almost exactly what I tried, but skipping over the skip_line seems to mean that it can't find the tag to read). Which seems weird. Is it possible that client->parser->input != client->input? Such that client->parser->input still points at the original fd?
Seems to solve the problem. Here's the patch (inlined), modified to make a new parser attached to the new fds. diff -ru dovecot-0.99.7/src/login/client.c dovecot-0.99.7p1/src/login/client.c --- dovecot-0.99.7/src/login/client.c 2003-01-11 17:29:47.000000000 +0200 +++ dovecot-0.99.7p1/src/login/client.c 2003-02-02 09:11:18.000000000 +0200 @@ -91,6 +91,9 @@ client->tls = TRUE; client_set_title(client); + /* we skipped it already, so don't ignore next command */ + client->skip_line = FALSE; + client->fd = fd_ssl; i_stream_unref(client->input); o_stream_unref(client->output); client->input = i_stream_create_file(fd_ssl, default_pool, 8192, FALSE); client->output = o_stream_create_file(fd_ssl, default_pool, 1024, IO_PRIORITY_DEFAULT, FALSE); + + imap_parser_destroy(client->parser); + client->parser = imap_parser_create(client->input, client->output, + MAX_INBUF_SIZE, + MAX_IMAP_ARG_ELEMENTS); } else { client_send_line(client, " * BYE TLS handehake failed."); client_destroy(client, "TLS handshake failed"); Amy! -- Amelia A. Lewis amyzing {at} talsever.com A hundred thousand lemmings can't be wrong.
On Sun, 2003-02-02 at 20:14, Amelia A.Lewis wrote:
Is it possible that client->parser->input != client->input? Such that client->parser->input still points at the original fd?
Seems to solve the problem. Here's the patch (inlined), modified to make a new parser attached to the new fds.
Hmm. I had fixed that already in CVS, but I though it was because I had changed something that required it. Wonder why that ever even worked..
participants (2)
-
Amelia A.Lewis
-
Timo Sirainen