List:General Discussion« Previous MessageNext Message »
From:Joerg Bruehe Date:February 25 2011 1:58pm
Subject:Re: Problems Connecting with SSL
View as plain text  
Hi Tim, all!


Sorry, but I have to start with a negative remark:
Why, oh why, don't you mention the version number you are using?

I hope it is some roughly current 5.1, but I'd rather like you to tell it.


Tim Gustafson wrote:
> I have three mySQL server, all of which are SSL-enable and all of which are generally
> accessible from remote clients over SSL.
> 
> However, one of my FreeBSD mySQL clients is having problems connecting to any of the
> servers.  Running mySQL under truss reports the following:
> 

Looking at this output tells something went terribly wrong:
file descriptor 2 is mishandled.

> ----------
> clock_gettime(13,{1298593067.000000000 })	 = 0 (0x0)
> open("/dev/urandom",O_RDONLY,00)		 = 4 (0x4)
> read(4,"\a\^V\M-)\^C\M-L{`\M^O\M^@\M-v"...,32)	 = 32 (0x20)
> sendto(2,"\^V\^C\^A\0Y\^A\0\0U\^C\^A\M-m"...,94,0x0,NULL,0x0) = 94 (0x5e)
> recvfrom(2,"\^V",1,0x2,NULL,0x0)		 = 1 (0x1)
> ioctl(2,FIONREAD,0xffffd784)			 = 0 (0x0)
> recvfrom(2,"\^V\^C\^A\0J\^B\0\0F\^C\^AMf\M-u"...,1819,0x0,NULL,0x0) = 1819 (0x71b)

In the above lines, socket calls 'sendto()' and 'recvfrom()' are applied
to FD 2. Whatever the transmitted data may be, this should not be done:
FD 2 is "standard error", so it is a file and no socket, and "receiving"
from it doesn't make any sense at all.

As the problem happens only for one of your combinations, I suspect that
 for some unknown reason FD 2 was closed in that run, and then this
number got returned when a socket was to be created.
Again, this should not happen: The only reason to close FD 2 should be
to re-open standard error to some other destination, which is unlikely
for the client to do.

> [[...]]
> shutdown(2,SHUT_RDWR)				 = 0 (0x0)
> close(2)					 = 0 (0x0)

So FD 2 is closed now.

> fstat(1,{ mode=crw--w---- ,inode=113,size=0,blksize=4096 }) = 0 (0x0)
> ioctl(1,TIOCGETA,0xffffe390)			 = 0 (0x0)
> write(2,"ERROR 2026 (HY000): ",20)		 ERR#9 'Bad file descriptor'
> write(2,"SSL connection error",20)		 ERR#9 'Bad file descriptor'
> write(2,"\n",1)					 ERR#9 'Bad file descriptor'

... but with a closed FD 2 there is no chance to output an error message.
(The operations on FD 1 also look suspicious to me.)

> write(1,"\a",1)					 = 1 (0x1)
> close(4)					 = 0 (0x0)
> process exit, rval = 1
> ----------
> 
> Can anyone tell me, based on the truss output above, what might be going wrong?  I'm
> using the exact same command line options and ssl-ca file that I am using on other
> clients, which can connect successfully.

I can't really tell what happened. It might be that file descriptor 2
(and probably also 1) were closed without good reason, and then creating
a socket (or opening some file) returned these descriptors.

You might check the preceding "truss" output for a "close(2)", IMO that
would likely be an error - but I have no idea why it happened.

> 
> (As an aside: feature request: better SSL connection debugging, please!)

I assume your SSL problems might just be a consequence of inappropriate
actions on FDs 1 and 2. Did you do any redirection, are you running into
"disk full", or is there any similar rsk on your stdout and stderr?


HTH,
Jörg

-- 
Joerg Bruehe,  MySQL Build Team,  joerg.bruehe@stripped
ORACLE Deutschland B.V. & Co. KG,   Komturstrasse 18a,   D-12099 Berlin
Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven
Amtsgericht Muenchen: HRA 95603

Thread
Problems Connecting with SSLTim Gustafson25 Feb
  • Re: Problems Connecting with SSLJoerg Bruehe25 Feb
    • Re: Problems Connecting with SSLTim Gustafson25 Feb
Re: Problems Connecting with SSLTim Gustafson25 Feb
Re: Problems Connecting with SSLTim Gustafson25 Feb
Re: Problems Connecting with SSLJoerg Bruehe25 Feb