Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jack_mort]

Hi,

I'm running amuled on my good old slackware, with amuleweb running. I can login from another computer on my LAN with no problem. Now, I wanted to test amulegui. But I can't seem to make it work, as it tells me "Authentication failed" when I enter the password. I also tried amulecmd, and the result is the same. External connections are allowed and locally (on the slackware box), amulecmd works. I also tried to launch amule/amuled on my gentoo box (with external connections allowed), and then try to connect from my slackware box, but I got the same problem  

Anyone got an idea ?

[phoenix]

jack_mort,

Two ideas:
1) Make sure both amuled and amulegui use the same protocol versions, i.e., make sure they are from the same tarball.
2) Look at the log file (~/aMule/logfile) in both the client and the server and look for something suspect there.

Cheers!

[jack_mort]

I'm using the same tarballs, compiled with the same configure options, and all it says in the log is "Authentication failed"...  

[Kry]

I've seeen it happen here also.

[ken]

Hmm.  Maybe a problem with hashing the password?  ?(

Can you copy the ~/.aMule/amule.conf from the account hosting amuled to the client machine (anywhere, it doesn't need to go in ~/.aMule) and do amulecmd --create-config-from=/path/to/the/copied/amule.conf.  Then try using amulecmd to connect -- it won't ask for the password from stdin.  Does that work?  Does amulegui now work from this client?

[jack_mort]

Yes, it worked !

But it's very strange... I backed up my config before overwriting it, and them made a diff on it, but the password line didn't appear in the result ?(

Anyway, thanks for your suggestion !

[ken]

What was different?  It would be good to figure out what was happening.

[jack_mort]

Well, actually nothing...

Maybe the storing of the password in amule.conf helped ? Before, I had to type the password...
Anyway, I'll try to investigate and see where the problem was. I'll keep you informed in few hours, or tomorrow.

[ken]

OK, I'm guessing you backed up and later diffed the amule.conf on the client account.  However, I would not have expected that to change.

All of the remote clients (amuleweb, amulecmd, amulegui) use ~/.aMule/remote.conf for their configuration information.  The command I had you run built the remote.conf file by copying the appropriate settings from the specified file (in this case, a copy of your server's amule.conf).

The existence of the remote.conf, and the password stored there, is the reason that amulecmd no longer needs you to type in the password when you run it.  If you temporarily rename remote.conf you will find that amulecmd goes back to its previous behavior.

So, the problem seems to be that when amulecmd asks for the password interactively, it doesn't hash it properly.  On the other hand, when it gets the hash from the remote.conf (which in turn got it from amule.conf), then everything works.

Things to try: rename remote.conf to remote.conf.saved and instead use amulecmd with its command-line options to specify all necessary parameters, including password.  Does that work?  Use amulecmd with the command-line options plus "-w" to create a new remote.conf.  How does the new remote.conf compare to remote.conf.saved?

When you have the answers to those, you can of course rename remote.conf.saved back to remote.conf.  

EDITED to add a thought: could this be a problem with either unicode or locale?  If a user enters a password at two different computers, but the encoding is different between them, will the hashes match?