Dave, thanks. > calling code was supposed to replace &d with a real value
You are right, of course. Stupid programmer tricks. Turns out &d is not the same thing as %d. Got that one solved. My client and my server code now make it through a certificate negotiation. Have not coded any farther as of today. I will look at your gethostbyname information. I do *have* the source code. (That's how I found the &d problem.) I use gethostbyname/gethostbyaddr all the time, but who knows. Thanks again, Charles -----Original Message----- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Monday, August 13, 2012 7:09 PM To: openssl-users@openssl.org Subject: RE: s_server gethostbyname failure > From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills > Sent: Monday, 13 August, 2012 11:32 > Found some things on the Web that led me to believe some programs > choke when they get IPv6 addresses back from gethostbyname(), so I > tried disabling IPv6 on Windows -- but no improvement. > > I have tried coding a server program more or less following the > example in the O'Reilly OpenSSL book and the first BIO_do_accept() > fails with > > 8276:error:02003AFC:system > library:getservbyname:reason(2812):.\crypto\bio\b_sock.c:224:s > ervice='&d' > > which I am going to guess is the same problem. > No, that's not the same problem. That says &d is not a valid "service" (which in TCP means port). And it isn't. It looks like some calling code was supposed to replace &d with a real value, probably a decimal number, but didn't. > From: owner-openssl-us...@openssl.org > [mailto:owner-openssl-us...@openssl.org] On Behalf Of CharlesTSR > Sent: Monday, August 13, 2012 9:15 AM > I have exactly the same problem as > http://old.nabble.com/s_server-and-gethostbyname-failure-error > -td14675962.ht > ml > http://old.nabble.com/s_server-and-gethostbyname-failure-error > -td14675962.ht > ml > . I have searched and don't find any replies. > > I run the following command: > openssl s_server -accept 6514 -cert servercacert.pem -key > servercakey.pem -state -debug -no_dhe > > OpenSSL responds > > Enter pass phrase for servercakey.pem: > Loading 'screen' into random state - done Using default temp ECDH > parameters ACCEPT > > When my client issues BIO_do_connect(conn) then openssl s_server fails > with > > gethostbyname failure > According to apps/s_socket.c that occurs if the address from which the client connected succeeds in gethostbyaddr (nominally reverse-DNS) but the resulting name fails in gethostbyname (nominally normal DNS). In my experience Windows often "enhances" DNS with data it decides would be helpful, and its decision isn't always perfect. > There is nothing particularly unusual about the Windows 7 64-bit > system on which openssl is running. I have used gethostbyaddr > frequently with no unexpected errors. I'm using a pre-built Windows > distribution of OpenSSL 1.0.1c. > Try a simple test program that does gethostbyaddr on the address your client is coming from and gethostbyname on the result, and see how they compare to what is correct for your network. Try running either your client code or s_client on other machine(s). ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
