Bug #1509

trouble auto-joining restricted channels on OFTC after client re-connect

Added by bill-auger almost 2 years ago. Updated 6 days ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


if i sign out cleanly manually, then reconnect manually, it auto-joins the restricted channel as expected - the problem seems to happen only when the client re-connects due to network dropout ("Disconnecting. (No Ping reply in 180 seconds.)") - on freenode with SASL this often results in an underscore being appended to my nick - it seems that both servers still consider me as signed in when quassel concludes has that i am disconnected

the symptom i noticed is this:

when i sign out cleanly then re-connect manually, i see "You are connected using SSL and have provided a matching client certificate .... You have been automatically identified." and everything proceeds as expected

but when the client re-connects itself automatically, i see "Nick already in use:" before it verifies the cert; and i do not see the "You have been automatically identified." message at all - in it's usual place is the error: "Cannot join channel (Need to be identified and verified to join this channel"


#1 Updated by Darkstar almost 2 years ago

This happened before in 0.12 too with Nickserv-based registrations. Reason is that the re-join happens too early, long before the Nickserv IDENT message is sent and acknowledged. Thus you have to re-join. It would be good to have an option to delay joining channels either by a fixed amount, or at least until Nickserv registration is done

#2 Updated by digitalcircuit almost 2 years ago

  • Target version set to Some future release

Sadly, OFTC still does not support SASL, which both of you noted as the proper network-dependent fix.

Adding a delay in Quassel might work this and other timing issues, though at this point it'd make more sense in 0.14+ as 0.13 is in maintenance and bugfixing (this is a long standing bug, not a new regression).

For now, my non-certificate workaround for OFTC is to put this in Commands to execute on connect

/ns identify PASSWORD your_nick
/wait 5; /ns reclaim your_nick
/wait 6; /nick your_nick

Alternatively, you could uncheck Rejoin all channels after reconnect and specify a bunch of manual /join #channel lines to run on connect.

#3 Updated by jjakob 3 months ago

I'm having the same issues, but using exclusively certificate certfp-based identify. It's my understanding there's no need for SASL password-based identify, as using a client certificate will use SASL EXTERNAL (that's what quassel-client says next to the SASL settings). But still, quassel starts to join channels before the server identifies my nick. IMO, a plain time delay isn't robust, as different conditions may cause the server-side identify to take longer than usual. It should wait for the server to say the nick is successfully identified before starting to join channels.

This is how every successful OFTC connection looks:

[14:04:52] [] *** Connected securely via TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384-256
[14:04:52] [] *** Your client certificate fingerprint is <REDACTED>
[14:04:52] * #suckless: Cannot join channel (Need to be identified and verified to join this channel, '/msg NickServ help' to learn how to register and verify.)
[14:04:52] *** Mode jjakob +R by jjakob
[14:04:52] [NickServ] This nickname is registered and protected.  If it is your nickname, you may
[14:04:52] [NickServ] authenticate yourself to services with the IDENTIFY command.  If you do
[14:04:52] [NickServ] not authenticate or change your nickname, I will change your nickname.  You
[14:04:52] [NickServ] are getting this notice because you are not on the access list for the jjakob
[14:04:52] [NickServ] nickname.
[14:04:52] [] Activating Cloak: <REDACTED>
[14:04:52] [NickServ] You are connected using SSL and have provided a matching client certificate
[14:04:52] [NickServ] for nickname jjakob.  You have been automatically identified.

I have to rejoin #suckless on every reconnect.

This is how a normal Freenode connection looks:

[14:29:46] * Connecting to
[14:29:46] * Requesting capability list...
[14:29:46] [] *** Looking up your hostname...
[14:29:46] [] *** Checking Ident
[14:29:46] [] *** Couldn't look up your hostname
[14:29:54] * Ready to negotiate (found: extended-join, identify-msg, chghost, away-notify, account-notify, sasl, multi-prefix, cap-notify, tls)
[14:29:54] * Negotiating capabilities (requesting: account-notify, away-notify, cap-notify, chghost, extended-join, multi-prefix)...
[14:29:54] [] *** No Ident response
[14:29:54] * Capability negotiation finished (enabled: account-notify, away-notify, cap-notify, chghost, extended-join, multi-prefix)
[14:29:54] * Welcome to the freenode Internet Relay Chat Network jjakob
[14:29:54] * Your host is[2a01:270:0:666f::1/6697], running version ircd-seven-1.1.9
<cut server info>
[14:29:54] *** Mode jjakob +Zi by jjakob
[14:29:54] [NickServ] This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>.
[14:29:54] [NickServ] You are now identified for jjakob.

No errors here, but sometimes it still fails to join some channels (this is from a previous connection):
[19:36:29] [NickServ] This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>.
[19:36:29] [NickServ] You are now identified for jjakob.
[19:36:36] * 470 #systemd-unregistered #systemd Forwarding to another channel

#4 Updated by digitalcircuit 3 months ago

After looking into this more, first I was mistaken, you do NOT have to enable the SASL checkbox jjakob, sorry for that. You'd only need to do that if OFTC actually supported SASL, which it does not. I overlooked that Quassel sets the certificate regardless of SASL before it even connects.

Secondly, OFTC does not support SASL.

[6:15:28 pm] [] *** No Ident response
[6:15:28 pm] * Ready to negotiate (found: multi-prefix)

If SASL was supported (password or certificate), the IRC server itself should cause Quassel to wait before it allows Quassel to try to join any channels.

IRCv3 Client Capability Negotiation

Upon receiving either a CAP LS or CAP REQ command during connection registration, the server MUST not complete registration until the client sends a CAP END command to indicate that capability negotiation has ended. This allows clients to request their desired capabilities before completing registration.

And Quassel does not send CAP END/continue caps until SASL authentication has completed, password or certificate.

Capability negotiation with SASL is the reliable way of handling authentication without plain time delays, so I don't think there'd be any way around this on Quassel's side other than introducing a timer, new client-side UI, protocol change with feature flag, and database change to store it.

Also available in: Atom PDF