badarg, [{ets, lookup, [crypto_server_table, port]},

Error

When trying to login, the following error message is displayed:

** Reason for termination =
** {badarg,[{ets,lookup,[crypto_server_table,port]},
{crypto,control,2},
{sha,sha,1},
{ejabberd_auth_internal,check_password,5},
{lists,any,2},
{ejabberd_c2s,wait_for_auth,2},
{gen_fsm,handle_msg,7},
{proc_lib,init_p,5}]}

Explanation

The crypto server has not been started.

Possible solutions

There are several reasons, and several solutions depending on the reason:

  • You installed ejabberd using a 32bit binary installer on a 64bit machine. You must use a 64bit binary installer, if available.
  • The original ejabberd 1.1.3 binary installer has some problems that need to be fixed. Until they are fixed and a new installer is released, you can use the ejabberd 1.1.2 installer. This particular bug is being tracked.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I found a solution for my system - might work for some of you

Hey folks,

I ran into this read error problem when installing (from source) ejabberd 2.0.0 on a RHEL 5 64bit Dell PowerEdge 1950.

Dell PowerEdge 1950
RHEL 5
Erlang R11B-5 (compiled from source)
expat 2.01 (compiled from source)
ejabberd 2.0.0 (compiled from source)
gcc 4.1

My old server was a 32bit desktop system that I was able to use a install package on. With our new 64bit server I was unable to find one that would work so I set about building from source.

What I found was an issue with compiling erlang with the defaults. I did NOT have to uninstall anything. I had to rebuild and install erlang.

From within my existing erlang src directory I entered the following commands:

./configure
make

Then I navigated to: %ERL_TOP%/lib/crypto/c_src
and entered this command:

gcc -shared  -o ../priv/lib/x86_64-unknown-linux-gnu/crypto_drv.so ../priv/obj/x86_64-unknown-linux-gnu/crypto_drv.o /usr/lib64/libcrypto.so

After this I moved back to the root of my erlang source folder and entered:

make install

After this all I had to do was stop, and then start my ejabberd server and all was well with the world. I found the reference to this fix here:
http://www.erlang.org/pipermail/erlang-patches/2007-November/000196.html

Hope this helps anyone else who may encounter this issue. Keep up the good work fellas!

Peace
Ross

crypto_drv.so

I had this problem today, and solved it with some tinkering.

I would guess this will only occur if the crypto server could not be started. To test this open an erlang shell and start the crypto server. You do this by entering "crypto:start()." without the quotation. If the crypto server can not be started this should yield alot of error messages when the server tries to start multiple times.

You can try loading the file like the crypto_server does. In crypto-1.5 it's done something like this:

crypto_server:init/0 wrote:

erl_ddll:start(),
PrivDir = code:priv_dir(crypto),
LibDir1 = filename:join([PrivDir, "lib"]),
erl_ddll:load_driver(LibDir1, crypto_drv).

erl_ddll:load_driver() returns ok on success and {error,Reason} on fail. The crypto_server tries with a different path after the first fail, but has no error handling for an error during this second load and just tries to run with it regardless of the outcome.

Among the error messages printed you will get a line, "sh: exec: crypto_drv not found", or something of the like. I've seen different versions of this error message on different platforms. One reason for this, and the reason my crypto server would not start, is that the crypto_server could not load crypto_drv.so because it's not linked properly. The file should be located in your erlang lib, under crypto-/priv/lib/, or something similar.

If this file exists, it's quite possible that the path it tries to find ssl libs for dynamic loading is wrong. I had to rebuild my crypto_drv.so file from the priv/obj folder with my Makefile's SO_SSL_LIBDIR variable changed to correspond to the location of my libssl.so and libcrypto.so files. Another way to fix this could be to symlink or copy the corresponding libssl.so and libcrypto.so files to /usr/local/lib, which I think is the default path to look for them.

If you have this error and this solution fixes it, you may also have some trouble with your lib/ssl-/priv/bin/ssl_esock file's dynamic library loading. Rebuilding this file, or copying or symlinking the lib files to /usr/local/lib might solve this issue too.

/Zxinn

Can't resolve this problem on Ubuntu6.1

Hi.. I'm having this same symptom... I've tried symlinking the libssl and libcryto .so files into /usr/local/lib... I've tried renaming those symlinks as libssl.so and libcrypto.so explicitly, instead of the long version names of the actual libs... I've tried reinstalling ejabberd after doing all that... still PSI cannot log in while Spark can... what can this mean?

Hi, I've had the same

Hi,
I've had the same problem but following workaround seems to work:
I don't know why but when i strace the erlang shell while starting crypto() i
see it searching for libcrypto.so.0.9.8 in lib/linux-x86 but the installer came with
libcrypto.so.0.9.7, after symlinking libcrypto.so.0.9.7 to libcrypto.so.0.9.8 crypto() started
without any other problems. Ejabberd also seems to work now.

Regards.

Syndicate content