OpenSSL errors (win32) #695

Closed
GoogleCodeExporter opened this Issue Mar 17, 2015 · 10 comments

Comments

Projects
None yet
1 participant
Upwards from r1333, I receive the following error alert while trying to start 
pennmush.exe:

pennmush.exe - Ordinal Not Found
The ordinal 444x could not be located in the dynamic link library LIBEAY32.dll.

A bit of research (and Cheetah) told me to upgrade OpenSSL, which I did (with a 
recompile of Penn relative to the newer libraries, of course). I am now running 
Win32-OpenSSL-1.0.0g. This error is still occurring.

I tried copying the new versions of both libeay32.dll and libssl32.dll to 
Windows/System32, overwriting the older version of 0.9.8.11 with the newer 
1.0.0.7. libssl32.dll was not previously present in the System32 directory. The 
error changed to "The ordinal 354 could not be located in the dynamic link 
library LIBEAY32.dll." A reboot returned the same results. 

When attempting to revert to r1332 (which worked with the old, overwritten dll, 
I received the same error. Deleting the v1.0.0.7 dll's and restoring the 
backed-up libeay32.dll v0.9.8.11 -in System32- fixed this problem. I am still 
running 

The most relevant information I could find regarding this error was a forum 
thread about another application attempting to use the SHA-1 algorithm (see 
http://bit.ly/yTn5j8).

Shining Light Productions has not released a Win32 distribution of OpenSSL 
1.0.1 Beta 2 (the latest from http://www.openssl.org).

Original issue reported on code.google.com by danielpo...@gmail.com on 5 Feb 2012 at 5:38

Pgph 5: I am still running OpenSSL 1.0.0g, and all in-game functions are still 
working, though the problem dll remains at 0.9.8.11 in order to support pre 
r1333.

Original comment by danielpo...@gmail.com on 5 Feb 2012 at 5:41

Some googling shows this seems to be a common issue when upgrading dlls, and 
the common answer seems to be to run 'regsrv32 foo.dll'

Original comment by alltheco...@gmail.com on 6 Feb 2012 at 4:14

  • Changed state: Accepted
  • Added labels: OpSys-Windows
regsvr32 libeay32.dll on version 1.0.0.7 returns "libeay32.dll was loaded, but 
the DllRegisterServer entry point was not found. The file cannot be 
registered." This is, I think, some internal handle on the library itself that 
allows it to work with the registry or whatever, and their solution is to just 
copy the file to System32 if that error is given.

Original comment by danielpo...@gmail.com on 6 Feb 2012 at 5:30

These previously-mentioned errors hav been resolved by copying libeay32.dll, 
libssl32.dll, and ssleay32.dll from OpenSSL-win32 to System32 or PennMUSH 
directory. Seems I was forgetting to copy ssleay32.dll as well, which caused 
conflict with the older version still in the System32 directory. Therefore, 
with these three newest version copied in, I am now no longer getting the 
"Ordinal not found" errors.

Still running into a few problems though during startup.

According to netmush.log, Penn makes it all the way through reading alias.cnf 
and restrict.cnf, but simply closes without any errors after that. "Seeding 
OpenSSL random number pool" line does NOT occur.

After upgrading these three relevant dll's within System32, this behavior 
began, even with the former revisions which worked with the old OpenSSL 
libraries in place. I'll attempt to look into this further to see if I can't 
track down what's going on.

Original comment by danielpo...@gmail.com on 7 Feb 2012 at 6:32

For some reason, I have resolved the final error, in the form of an uncaught 
exception. This included numerous reinstalls of OpenSSL switching between 
1.0.0e, 0.9.8t, back up to 1.0.0g, and on and on it went. Finally, I switched 
my linker over to the static OpenSSL libraries, and managed to finally catch 
the error, which was some assertion failure somewhere that I'd seen before. 

For some very strange reason, I attempted to start Penn a final time (with 
VC/static/libeay32MD.lib and VC/static/ssleay32MD.lib being the called 
libraries, which does double the size of the PennMUSH.exe binary, but I'm 
willing to deal with it for now), and it, for no apparent reason, decided to 
just work.

However, now that I think about it, it MAY have been due somehow to the port 
message program I executed before starting Penn the final time. Thought that 
maybe the port wasn't properly closed, though that doesn't make sense, as this 
behavior of Penn killing itself without warning was also occurring on the 
backup (different port). In the end, in my mind, I'm currently running an 
unstable server, as I don't know exactly what's keeping it together in terms of 
this SSL library thing.

Converted God password via the utility (which for some reason also converted 
the other players), and I seem to be back up and running with latest Penn 
revision and latest OpenSSL libraries.

As some sort of issue resolution to this issue, here's an updated 
win32/README_OpenSSL.txt file.

Original comment by danielpo...@gmail.com on 7 Feb 2012 at 9:45

Attachments:

How did you invoke pwutil?

The game should be recognizing that it can't bind to a particular port if it's 
already in use and not start up, but it should be logging about that.

If it's working with a statically linked ssl library but not dynamic, a wild 
guess is that with all the different versions floating around, Windows isn't 
loading whatever one you actually intend.



Original comment by alltheco...@gmail.com on 8 Feb 2012 at 1:08

pwutil attempt 1: perl utils/pwutil.pl --sha 1 --set 1 TFG/data/indb
   > Requires password
   > C:\PennMUSH\
pwutil attempt 2: perl utils/pwutil.pl --sha 1 --set 1 --password <god pwd> 
TFG/data/indb
   > Adding password to object 1
   > Adding password to object 1
   > Adding password to object 1
   > Adding password to object 1
    ...
    ...
    Runaway loop
    ...
    ...
   > Adding password to object 1
   > C:\PennMUSH\
pwutil attempt 3: perl utils/pwutil.pl --wipe 1 TFG/data/indb
   > Clearing password from object 1
   > Clearing password from object 1
   > Clearing password from object 1
    ...
    ...
    Runaway loop
    ...
    ...
   > Clearing password from object 1
   > C:\PennMUSH>

Setting the password on God boosted the actual database size by nearly 200KB. 
Clearing it brought it down to below the size it was before, and after I 
cleared God password, it seemed that all user passwords, except for a select 
few (bots being my discovered example) worked instead of giving me the standard 
"User not found or incorrect password." And the God password was in fact 
cleared, but the others were functioning normally. I've just decided to add a 
little notification on my connect screen to login as guest and manually request 
a password reset if they can't get in. I've catalogued IPs with player names, 
so it shouldn't be too much of a security risk, and besides, I've only got 
something like 20 actual players.

As for static versus dynamic libraries, that's the same conclusion I came up 
with. The fact that it's working now makes me want to just leave it, but I'm 
going to look into getting it fixed up anyway, just to decrease executable size 
and make things a little nicer for future updates. Perhaps pulling the SSL 
dynamic libraries directly into the PennMUSH directory would bypass any 
environment path problems. Apache does it. Penn could too.

Original comment by danielpo...@gmail.com on 8 Feb 2012 at 4:57

Doh. Brown paper bag commit coming up (That's why the script makes backups.) I 
forgot a $ in a re and it was working on every dbref starting with 1. 

Original comment by alltheco...@gmail.com on 9 Feb 2012 at 12:06

Updated win32/README_OpenSSL.txt from your latest.

Original comment by alltheco...@gmail.com on 10 Feb 2012 at 2:34

The Win32 build information is maintained at 
http://code.google.com/p/pennmush/wiki/Win32Build

I'll try to update it sometime to reference the DLLs that need to be copied 
over. Ideally it'd be nice if all this could happen magically but it's not so 
simple to do that...

Original comment by zetafunc...@gmail.com on 21 Aug 2012 at 12:00

  • Changed state: Fixed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment