"Password mismatch" problem

These are old archives. They are kept for historic purposes only.
Post Reply
Rasbelin
Posts: 4
Joined: Thu Jul 29, 2004 11:53 am
Location: Tampere, Finland

"Password mismatch" problem

Post by Rasbelin »

I have read the documentation and FAQ carefully, plus checked the forums for previous discussions about this topic, but failed to find a working solution to my problem.

I'm currently running version 3.2.1 and I get the following problem, when I try to connect to the IRCd with an allow password. It doesn't matter what the password is or if ident is in use in my IRC client. And neither is it a client specific issue. When I try to connect, it returns the following:
[03:27:02] Looking up irc.something.com...
[03:27:02] Connecting to ********, port 6667
[03:27:02] Sending login information...
[03:27:04] -irc.something.com- *** Looking up your hostname...
[03:27:04] -irc.something.com- *** Found your hostname (cached)
[03:27:04] -irc.something.com- *** Checking ident...
[03:27:07] -irc.something.com- *** No ident response; username prefixed with ~
[03:27:07] -irc.something.com- Closing Link: Rasbelin[some.isp.that.has.been.censored.info] (Password mismatch)
So it looks like the provided password doesn't match, despite it should.

The configuration used for the allow block:

Code: Select all

allow {
	ip             *@*;
	hostname       *@*;
	class           clients;
	password "test";
	maxperip 5;
};

allow {
	ip             *@*;
	hostname       *@*;
	class           servers;
    password "*********";
	maxperip 1;
	options {
	    nopasscont; 
	};
};
I have narrowed down the issue to be with this, while using a password (without any password, it works just as supposed to), but can't really get the clue, what on Earth causes the problem. :?

I appriciate any useful hints you may have.
Syzop
UnrealIRCd head coder
Posts: 2179
Joined: Sat Mar 06, 2004 8:57 pm
Location: .nl
Contact:

Post by Syzop »

I'm not entirely sure what you are trying to accomplish, but...
The 'nopasscont' means exactly that: if no password is provided, continue.
So if anyone provides a wrong (for the latest block) password, then it's handled as a 'Password mismatch' and it does not continue.
There's currently no 'wrongpasscont' or something (although that might not be a bad idea :p).
Rasbelin
Posts: 4
Joined: Thu Jul 29, 2004 11:53 am
Location: Tampere, Finland

Post by Rasbelin »

Syzop wrote:I'm not entirely sure what you are trying to accomplish
I'm trying to accomplish the following:

1) If the connecting connection provides a password and it matches the allow password for the class dedicated to servers, it's granted access in the servers class.

2) If there's no password, the connection is passed to the next allow class, which is the allow class for regular client connections. If the password is wrong, the user cannot connect and the connection is cut off.
The 'nopasscont' means exactly that: if no password is provided, continue. So if anyone provides a wrong (for the latest block) password, then it's handled as a 'Password mismatch' and it does not continue.
There's currently no 'wrongpasscont' or something (although that might not be a bad idea :p).
Yes, it continues to the second allow section as supposed to, but then it stalls, even if the password would be correct. That's the issue. Not the initial allow section. BTW, the documentation doesn't mention wrongpasscont.
Rasbelin
Posts: 4
Joined: Thu Jul 29, 2004 11:53 am
Location: Tampere, Finland

Post by Rasbelin »

I tried adding the wrongpasscont line into the options section for server connections, but that doesn't change anything. It still seems to stall in the 2nd section of the allow block.
aquanight
Official supporter
Posts: 862
Joined: Tue Mar 09, 2004 10:47 pm
Location: Boise, ID

Post by aquanight »

That's because wrongpasscont doesn't exist.
Rasbelin
Posts: 4
Joined: Thu Jul 29, 2004 11:53 am
Location: Tampere, Finland

Post by Rasbelin »

Any other suggestions? I still experience this problem. So far no solutions that would be helpful.
MrUnsocial
Posts: 3
Joined: Sun Apr 18, 2004 4:28 am

Post by MrUnsocial »

The only fix I could find was for the users to specify port 6660 like
/server server.address:6660 password
when I had my network password protected else they would get the pass mismatch too.
Post Reply