Bug #746
Quassel unsets default modes set by server upon first connect
| Status: | Resolved | Start date: | 07/15/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 100% |
|
| Category: | - | |||
| Target version: | 0.6.2 | |||
| Version: | 0.4.1 | OS: | Any |
Description
Quassel appears to unset the default modes set by a server upon the first connect.
Steps to reproduce:
1. Connect to an IRC network which by default sets modes on connect (like UnrealIRCd based networks, which set mode +x (host cloaking) by default)
2. Notice default modes being set by the server, and unset by the client:
[10:22:27] * Mode niekie +iwRx by niekie
[10:22:27] * Mode niekie -iwRx by niekie
Workaround:
Setting back these modes manually will make Quassel remember them, however, and it will not unset them the next time you connect.
Expected behaviour:
Quassel should either not unset modes that are being forced upon it by the server (this may also prevent issues in case a server keeps setting modes if a client unsets them) or should "cache" the modes that are being forced upon it on first connect and only unset them if the client manually unsets them.
Associated revisions
Fixes #746 - Quassel unsets default modes set by server upon first connect
Quassel now uses a saner approach and only keeps track of the mode changes you
really issued and also were confirmed by the server.
You can reset the auto restore modes via "/mode -reset". This command gives
currently no userfeedback as it would introduce new strings and this patch
is intended to be backported.
Fixes #746 - Quassel unsets default modes set by server upon first connect
Quassel now uses a saner approach and only keeps track of the mode changes you
really issued and also were confirmed by the server.
You can reset the auto restore modes via "/mode -reset". This command gives
currently no userfeedback as it would introduce new strings and this patch
is intended to be backported.
History
#1 Updated by dalbers almost 3 years ago
The attached patch is untested and pretty cruel, but may be a good starting point for someone else looking into this issue.
#2 Updated by ktr over 2 years ago
Problems with the auto usermodes after reconnect.
(all encountered on quakenet)
quassel is set to use usermode +x. this cloaks your host to auth.users.quakenet.org if logged in.
but if you want to use auth without cloaking and quassel has set +x before on quakenet, there is no way to remove the +x on connect (if you disconnect, remove the auth from perform and even set "/mode nick -x" in the perform).
it always sets +x after a while.
could recreate this bug(?) on another core. just connected to quakenet, set usermode +x without using the qauth, wrote "mode nick -x" in the perform and restarted the core.
after connecting with the client, usermode was set again to +x.
if i tried to disconnect from the core just after it reconnected to the ircd, the client even froze.
client is the same (from datafreak quasselclient[shared, 3.feb.2010]) tested cores are static0.5-0.1 and a core built from the git on 23.jan.2010.
#3 Updated by ktr over 2 years ago
just after sending the report i "found" smth like a solution.
tested successfully with both cores:
added a few lines "/mode nick -x" in the perform to spam the ircd on connect.
connected, confirmed that it does not set +x (just the, i guess default, +i on quakenet, had to be quick, in recent tries it showed, that i had only around 5-10sec until +x comes around) and immediately disconnected the core from the ircd.
again connected the core to the network and disconnected the client from the core (again a freeze here).
this somehow didnt set +x.
#4 Updated by EgS about 2 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Applied in changeset a2e242f1796406f13f5aa77413180ea1b2f6c607.
#5 Updated by johu about 2 years ago
- Target version set to 0.6.2