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.
-> 22.214.171.124 CAP LS
-> 126.96.36.199 NICK Raccoon
-> 188.8.131.52 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
-> 184.108.40.206 CAP REQ :userhost-in-names
-> 220.127.116.11 CAP REQ :multi-prefix
-> 18.104.22.168 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
-> 22.214.171.124 CAP LIST
-> 126.96.36.199 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.