ZNC seems to not properly sync NAMES output on some networks
Found configurations:
"protect" prefix is "!" PREFIX=(qaohv)*!@%+ (UnrealIRCd-4.0.15)
sample network: irc.bullet-irc.net
The /NAMES output will be empty if you reconnect to znc from a channel with a protect in it. A manual /NAMES #Channel resyncs the client.
refer to conversation at 2018-05-06 (~19:00 UTC) between Zarthus and Azo1 for full logs
1.7.0 regression (works in 1.6.6)
ZNC seems to not properly sync NAMES output on some networks
Found configurations:
- "protect" prefix is "!" `PREFIX=(qaohv)*!@%+` (UnrealIRCd-4.0.15)
- sample network: irc.bullet-irc.net
The /NAMES output will be empty if you reconnect to znc from a channel with a protect in it. A manual `/NAMES #Channel` resyncs the client.
refer to conversation at 2018-05-06 (~19:00 UTC) between Zarthus and Azo1 for full logs
<!-- github-sync-id:320618536 -->
if the network doesn't give owner rights to new channel creations it might be hard to reproduce painlessly, but existing channels should work and probably exists in /list.
No,
if the network doesn't give owner rights to new channel creations it might be hard to reproduce painlessly, but existing channels should work and probably exists in /list.
<!-- github-comment-id:388589944 -->
So... ZNC turned !ChanServ!chanserv@services. into ChanServ here, but should have turned it into !ChanServ.
The code causing this is the handling of numeric 353 in Client::PutClient. If the IRC connection has UHNames, but the client connection has not, this does sNick = sNick.Token(0, false, "!"). Instead... this should be doing something else. No idea how to easily do this in a non-ugly way, but at least it should be relatively easy to write a test for this.
(CChan::AddNick does some semi-complex parsing that would work fine here, but that needs quite some code. All chars at the beginning for which CIRCSock::IsPermChar returns true must be preserved/ignored)
```
:networkname. 353 testuser @ #test :!ChanServ!chanserv@services. testuser!testuser@magical.unicorn
:networkname. 353 testuser @ #test :ChanServ testuser
```
So... ZNC turned `!ChanServ!chanserv@services.` into `ChanServ` here, but should have turned it into `!ChanServ`.
The code causing this is the handling of numeric `353` in `Client::PutClient`. If the IRC connection has UHNames, but the client connection has not, this does `sNick = sNick.Token(0, false, "!")`. Instead... this should be doing something else. No idea how to easily do this in a non-ugly way, but at least it should be relatively easy to write a test for this.
(`CChan::AddNick` does some semi-complex parsing that would work fine here, but that needs quite some code. All chars at the beginning for which `CIRCSock::IsPermChar` returns `true` must be preserved/ignored)
<!-- github-comment-id:416030061 -->
Just updated my oldish ZNC installation to 1.7.4-rc1, and connecting to a inspircd3 with a couple of custom prefixes, this is still an issue.
Doing a /name #channel updates userlist to be correct, but userlist is not correct on initial connect.
Just updated my oldish ZNC installation to 1.7.4-rc1, and connecting to a inspircd3 with a couple of custom prefixes, this is still an issue.
Doing a /name #channel updates userlist to be correct, but userlist is not correct on initial connect.
<!-- github-comment-id:504210150 -->
Just updated my oldish ZNC installation to 1.7.4-rc1, and connecting to a inspircd3 with a couple of custom prefixes, this is still an issue.
Doing a /name #channel updates userlist to be correct, but userlist is not correct on initial connect.
Can confirm (znc 1.7.5), as inspircd3.0 was released and more and more networks will switch over to it it might be worth looking into this again.
> Just updated my oldish ZNC installation to 1.7.4-rc1, and connecting to a inspircd3 with a couple of custom prefixes, this is still an issue.
>
> Doing a /name #channel updates userlist to be correct, but userlist is not correct on initial connect.
Can confirm (znc 1.7.5), as inspircd3.0 was released and more and more networks will switch over to it it might be worth looking into this again.
<!-- github-comment-id:538768361 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
1.7.0 regression (works in 1.6.6)
ZNC seems to not properly sync NAMES output on some networks
Found configurations:
PREFIX=(qaohv)*!@%+(UnrealIRCd-4.0.15)The /NAMES output will be empty if you reconnect to znc from a channel with a protect in it. A manual
/NAMES #Channelresyncs the client.refer to conversation at 2018-05-06 (~19:00 UTC) between Zarthus and Azo1 for full logs
Do you have an example channel with this?
When I tried
mode +a, it said499 ... :You're not a channel ownerNo,
if the network doesn't give owner rights to new channel creations it might be hard to reproduce painlessly, but existing channels should work and probably exists in /list.
I can't reproduce this. Need full log of
znc -D(except for passwords, of course)On behalf of
fasm,http://ix.io/1ld6
Conversation between 12:00 - 13:00 (UTC), 2018-08-25
So... ZNC turned
!ChanServ!chanserv@services.intoChanServhere, but should have turned it into!ChanServ.The code causing this is the handling of numeric
353inClient::PutClient. If the IRC connection has UHNames, but the client connection has not, this doessNick = sNick.Token(0, false, "!"). Instead... this should be doing something else. No idea how to easily do this in a non-ugly way, but at least it should be relatively easy to write a test for this.(
CChan::AddNickdoes some semi-complex parsing that would work fine here, but that needs quite some code. All chars at the beginning for whichCIRCSock::IsPermCharreturnstruemust be preserved/ignored)Just updated my oldish ZNC installation to 1.7.4-rc1, and connecting to a inspircd3 with a couple of custom prefixes, this is still an issue.
Doing a /name #channel updates userlist to be correct, but userlist is not correct on initial connect.
Can confirm (znc 1.7.5), as inspircd3.0 was released and more and more networks will switch over to it it might be worth looking into this again.
Its still an issue here, at least, users are scripting their way out of it, but its not an ideal solution.
Is this a solution?
src/Client.cpp
replace
sNick = sNick.Token(0, false, "!");
with
size_t uPrefixLen = 0;
while (uPrefixLen < sNick.size() &&
pIRCSock->IsPermChar(sNick[uPrefixLen])) {
++uPrefixLen;
}
CString sPrefix = sNick.substr(0, uPrefixLen);
CString sNickWithoutPrefix = sNick.substr(uPrefixLen);
sNick = sPrefix + sNickWithoutPrefix.Token(0, false, "!");