Similar topic here; different(?) bug I'd like to report for beta v7.47.489
All of my ZNC servers I have saved will not connect. They all have passwords (as required by ZNC). The method is "Server Password (/PASS)" (default).
Watching the /debug window, the PASS command is not being sent.
-> 123.123.123.123 CAP LS
-> 123.123.123.123 NICK Raccoon
-> 123.123.123.123 USER racccoon 0 * :raccoon
<- :irc.znc.in CAP unknown-nick LS :userhost-in-names multi-prefix znc.in/server-time-iso znc.in/batch znc.in/self-message
-> 123.123.123.123 CAP REQ :userhost-in-names
-> 123.123.123.123 CAP REQ :multi-prefix
-> 123.123.123.123 CAP REQ :znc.in/server-time-iso
<- :irc.znc.in CAP Raccoon ACK :userhost-in-names
<- :irc.znc.in CAP Raccoon ACK :multi-prefix
<- :irc.znc.in CAP Raccoon ACK :znc.in/server-time-iso
-> 123.123.123.123 CAP LIST
-> 123.123.123.123 CAP END
<- :irc.znc.in CAP Raccoon LIST :multi-prefix userhost-in-names znc.in/server-time-iso
<- :irc.znc.in 464 Raccoon :Password required
<- :irc.znc.in NOTICE AUTH :*** You need to send your password. Configure your client to send a server password.
<- :irc.znc.in NOTICE AUTH :*** To connect now, you can use /quote PASS <username>:<password>, or /quote PASS <username>/<network>:<password> to connect to a specific network.
Suggestion: At numeric 464 "Password required" you might send along the PASS command command as a failsafe measure, too, regardless of the selected non-encrypted authentication method chosen by the user.
On a design note: I recommend always sending the PASS command, even if a user chooses SASL PLAIN, as it typically behaves as a fallback method of authentication. That is, if SASL PLAIN fails to authenticate in time due to laggy services or netsplits, the PASS command will lag along in queue and may eventually find its destination. But that's surely up for argument, too. But PASS + SASL PLAIN together has never hurt anybody.
Last edited by Raccoon; 20/02/17 05:09 PM.
