View Issue Details

IDProjectCategoryView StatusLast Update
0005566unrealircdpublic2020-04-18 18:56
Reporterarmyn Assigned Tosyzop  
PrioritynormalSeveritymajorReproducibilitysometimes
Status resolvedResolutionfixed 
OSCentOS OS Version7.7 
Product Version5.0.3.1 
Fixed in Version5.0.4 
Summary0005566: Problem with shun (/shun and shun of spamfilter)
DescriptionFrom time to time the shun applied to a user does not work, he can still write and this without logging out. He can also leave the canal and come back. This whole problem is random and probably won't happen on in first 10 "/shun" you start.

The spamfilter shun is also affected by this same problem and the user can still write.
This problem exists on all unrealircd 5 versions (currently I have 5.0.3.1 and the problem still exists).
Steps To ReproduceImpossible to describe it like that.
You should just put a shun (/shun [nick])
and then [nick] he has to write on the channel, if his message doesn't get through then he will never get through. The test is over so you need the "unshun".
Repeat the shun and write, at some point the user will be able to write.
This problem should be reproduced under the same conditions as my configuration, that is to say:

- CentOS 7.7
- UnrealIRCd alone (without any link with other serveur ircd)
- UnrealIRCd 5.0.0 to 5.0.3.1 (all tested, the problem exists on all)
- Normal configuration of unrealircd.conf file (basic)
- The core of UnrealIRCd has been changed a bit ( activation nofakelag on config.h / modification in tkl.c for "no reason" to "indésirable" / #define USERLEN 10 to #define USERLEN 20 in struct.h)
- The modules installed is: authpass-5.0, Monitor-5.0.2, geoip-base, geoip-whois, nicksuffix, showwebirc2 The modules have been disabled but the problem still seems to exist for the test.
TagsNo tags attached.
3rd party modules

Activities

syzop

2020-02-12 19:54

administrator   ~0021325

Just to be sure, could you run: make clean; make; make install
and make sure to have no 3rd party modules in your configuration file
then restart the ircd and see if you can reproduce the issue?

I could not reproduce it on my testnet, tried multi-server too.

If you still have the issue, then please post a bug note here with a full example of you SHUN'ing a user and the user still being able to send messages. So I would like to see the SHUN being added (the shun notice) and then the user still being able to send messages in the channel, for several seconds later, including timestamps.

You can post that note as 'private' if it contains sensitive information like IP addresses.

Lord255

2020-02-12 22:14

reporter   ~0021327

we also tried to reproduce this with westor (cuz the issue goes way back to around release of 5.0.1?), but we were unable to.
reported said he didn't have any 3rd party modules at all, but tempered with source code, however we (westor and me) were unable to reproduce this at all.

syzop

2020-02-13 18:05

administrator   ~0021329

The only thing I can see is a small delay between applying a shun and it having effect. This should be 1 second maximum and has to do with applying shuns in the main loop.
Have you ever been able to have the shunned user send messages for many seconds?
I know you showed a single message supposedly 4 seconds after the SHUN, but... I am just wondering if you can make it send for like 10 20 30 seconds or something like that after the SHUN.

syzop

2020-02-13 18:14

administrator   ~0021330

See previous message, but just to add: I also tried with (faking) the exact IP you tried and all the except ... { } lines that you have. Same result.

syzop

2020-02-13 18:17

administrator   ~0021331

Last edited: 2020-02-13 18:56

And a 3rd message: perhaps you have a bad /ELINE? To list all exceptions (both configuration items AND items added via the /ELINE command) type "/STATS except" on IRC.

syzop

2020-03-11 13:10

administrator   ~0021361

Last edited: 2020-03-11 13:11

I have been on vacation for 2 weeks and haven't done much since I got back but:
I have spent at least 2-3 hours on this issue, trying to duplicate it but am unable to. Other people have tried to duplicate it too but were unable to. As far as we know, right now it is only you that experiences this bug.
So this could be a real bug, but when others cannot duplicate it (especially me) it makes it difficult to find and fix the issue.

I have not yet tried with your configuration from the latest two (private) posts, with your entire set { } block settings etc. So I can still do that.

armyn

2020-03-11 13:23

reporter   ~0021362

Hi

Currently:

1) I type /shun Niva (via Admin)
2) With "Niva", I type message on channel: u
3) Message 'u' not sent (good)
4) with Niva, I flood "u" per second / limited to 10 or 50 - At the end the messages go past, they can be read by Admin and all the others

Lord255

2020-03-11 13:33

reporter   ~0021363

joined a chan as oper and a simple user too
user is able to send msgs to the chan
i put a shun on user's nick, the user is not able to send any msgs to the chan anymore.
tried to set a few timers to spam, but the shun is there and no msg goes through to the chan.

Le_Coyote

2020-03-16 22:21

reporter   ~0021371

I can confirm that there was at least one instance where we were hit by this bug. The SHUN was placed by an IRCOp connected to a leaf server running 4.0.18, and the shun target was connected to another, newly upgraded, leaf running 5.0.3.1. After the shun was placed, the targeted user could still speak on public channels.
We have not been able to reproduce this consistently (we did not try, really), but we definitely came across it accidentally on servers with no source code modifications and only m_alias (adapted to 5.x) as 3rd party module.

Lord255

2020-03-16 22:55

reporter   ~0021372

i think thats a different issue mr_smoke.
this report says all unreal5 versions are affected. who were tried to reproduce the issue used v5.* only. (i presume. at least i did.)
since v5 is out, i would recommend you and for everyone, to update their v4.* servers to v5.*, since you and all of you have already some v5.* servers (because you say the issue is coming when both v5 and v4 are used).
if the bug not exists for v5.* linked to v5.* only, i would just close this case. v4 comes to its end, however to choice is always in syzop's hand :)
(tbh, i wdoulnt care much for v4.* reports, cuz v5 is out now and all v4.* should be upgraded to v5 anyways)

Le_Coyote

2020-03-17 00:38

reporter   ~0021373

Well, since this issue had *never* cropped up before we introduced 5.x to our network, I'm tempted to say it's not entirely unrelated. And even if it were caused by 4.x/5.x cohabitation and not just 5.x on its own, it would still be related to this bug somehow :)

Lord255

2020-03-17 09:37

reporter   ~0021374

i'm only pointing to the report description, which is basically never said anything about v4 connection. so that's why i'm saying it's two different issues. :)
if the description or the reproduction part would say, that there is a v4 server in the network, then yes. all good. but for me, this is a different issue.
for the two case, the debugging is different. but maybe the report didn't mention this important info that one of the or more servers are v4.

armyn

2020-03-17 13:28

reporter   ~0021375

My problem with Unreal 5. * does not concern Unreal 4, I never encountered this problem on Unreal 4.
But I must admit that UnrealIRCd 4.0.22 is installed on the dedicated server but not running. Unrealircd 5 (latest version) is running.


You talked about "m_alias" and that gave me an idea, I will have to delete the custom aliases to see if the shun bug is fixed!

Maybe there is a problem with "spamfilter no;" I have lots

GHF

2020-03-27 09:32

reporter   ~0021388

I just realized shunned user is still chatting.
All servers are latest version UnrealIRCd-5.0.3.1
Module list:
 third/operoverride_ext 2.0 - Additional OperOverride functionality - by Gottem [3RD]
 third/geoip-whois 5.0.1 - Add country info to /whois - by k4be@PIRC [3RD]
 third/geoip-base 5.0.1 - GeoIP data provider module - by k4be@PIRC [3RD]
 third/banfix_voice 2.0 - Correct some odd behaviour in regards to banned-but-voiced users - by Gottem [3RD]
 third/plainusers 2.0 - Allows opers to list all users NOT connected over SSL/TLS - by Gottem [3RD]
 third/extwarn 2.0 - Enables additional configuration error checking - by Gottem [3RD]
 third/fixhop 2.0 - The +h access mode seems to be a little borked/limited, this module implements some tweaks for it - by Gottem [3RD]
 third/debug 2.0 - Allows privileged opers to easily view internal (configuration) data - by Gottem [3RD]

I havent tried with disabled modules

armyn

2020-04-03 09:05

reporter   ~0021397

7) Hide the modules from the public by editing src / modules.c (803) by adding:
     if (! IsOper (client))
     {
         / * sendnotice (sptr, "command disabled"); * /
         return;
     }


Whenever I install unrealircd 5 (and 4 before), I apply this modification, it works well but maybe it causes other problems for shun ...?

Le_Coyote

2020-04-05 18:47

reporter   ~0021401

I can confirm the bug once again, and now our whole network is running 5.0.3.1
An IRCOp set a shun on *@x.x.x.x, and a matching user was able to speak on channels for the following 30 minutes or so, until they left.
Both the IRCOp and the target user were connected to the same server, so that would probably rule out any link syncing issues.
The shun was not a soft shun. No exceptions (ELINEs) matched the target user. No error messages were found in that server's logs around the time the shun was created or afterwards. But we still can't reproduce this bug consistently :/

syzop

2020-04-10 19:41

administrator   ~0021412

Interesting to see it affects more people now. I'll take another look soon.

syzop

2020-04-12 09:12

administrator   ~0021434

I so wished I was able to reproduce this. Still am unable to :(
I've tried multi-server setups, but I am sure I tried in the past, 1 hop away, 2 hops away, does not matter, shun works. Then again, anyone affected by this bug also reports it is not 100% reproducible.

One or two asked/reported and yes I am indeed only interested in cases with 0 code modifications and 0 third party modules, otherwise there are just too much possibilities for things to go wrong elsewhere.

syzop

2020-04-12 09:18

administrator   ~0021435

For the people affect by this bug: do you see any messages in the log (or on IRC, as an oper) between placing the SHUN and the next xx seconds when it does not have any affect? Something happening? A clue?
I'm basically looking for some additional factor that apparently must be influencing whether this bug does or does not occur...

syzop

2020-04-12 10:05

administrator   ~0021436

Could everyone who thinks he/she is experiencing this bug install the new module that I just created.
1) Run this on the shell: ./unrealircd module install third/tracetklbug
2) Load the module in the unrealircd.conf (or whatever conf you use): loadmodule "third/tracetklbug";
You will have to do this on all your servers (including hubs) if you want to trace this across links.

This module introduces a new command: /TRACETKLBUG nickname
Just run /TRACETKLBUG name-of-shunned-user whenever you think a shun is not working on name-of-shunned-user. You can also just run it on anyone just for testing purposes, it should not harm anyone.
The command will spit a couple of lines of information. The command is IRCOp-only, of course.

Thanks everyone in advance for helping with this by doing the above!

syzop

2020-04-12 10:07

administrator   ~0021437

Also I changed my mind: if you run 3rd party modules then you can still do this tracing... just be sure to mention what 3rd party modules you are using. It could be relevant.

armyn

2020-04-12 17:54

reporter   ~0021457

Test:

#1
- Niva is shun
- /shun Niva (24hours in default)
[17:38:03] SNotice *** Shun added for *@212.47.xx on Sun Apr 12 15:38:21 2020 GMT (from [email protected] to expire at Mon Apr 13 15:38:21 2020 GMT: indésirable)

#2
- I immediately type this: : /TRACETKLBUG Niva - He returns: [17:38:08] SNotice User was already shunned (TRACETKLBUG did not change this)
- Niva is blocked for a few seconds but after 5-10 seconds it can write without being blocked and so I type this: /TRACETKLBUG Niva - He returns: [17:38:20] SNotice User was not shunned before. User got shunned now once you issued /TRACETKLBUG. loop.do_bancheck was zero, so this should not have happened!.

#3
- now i delete the shun: /shun -Niva
[17:41:53] SNotice *** [email protected] removed Shun *@212.47.x.x (set at Sun Apr 12 15:38:21 2020 - reason: indésirable)
- Now I type this: /TRACETKLBUG Niva
He returns: [17:42:39] SNotice User is NOT shunned. TKL system thinks it should not shun this user.



- The modules installed is: authpass-5.0, Traffic-5.0.3, geoip-base, geoip-whois, nicksuffix, showwebirc2 (showwebirc with line in FR)

Full list:

/* This file will load (nearly) all modules available on UnrealIRCd.
 * So all commands, channel modes, user modes, etc..
 *
 * If you want to have all UnrealIRCd functionality, then include this
 * file from your unrealircd.conf by using:
 * include "modules.default.conf";
 *
 * DO NOT EDIT THIS FILE! IT WILL BE OVERWRITTEN DURING NEXT UPGRADE!!
 * If you want to customize the modules to load you have two options:
 * 1) Keep the include for modules.default.conf as usual and make use
 * of blacklist-module "xyz"; to selectively disable modules.
 * See https://www.unrealircd.org/docs/Blacklist-module_directive
 * 2) OR, make a copy of this file (eg: name it modules.custom.conf)
 * and edit it. Then include that file from your unrealircd.conf
 * instead of this one.
 * The downside of option #2 is that you will need to track changes
 * in the original modules.default.conf with each new UnrealIRCd
 * release to make sure you don't miss any new functionality (as new
 * important modules may be added you need to add them to your conf).
 * You don't have this problem with option #1.
 */

/*** Cloaking (for user mode +x) ***/
loadmodule "cloak";


/*** Commands ***/

// User commands (MINIMAL)
// These provide just the minimal set of IRC commands that are
// required by RFC1459 along with WATCH and MAP.
loadmodule "admin";
loadmodule "away";
loadmodule "invite";
loadmodule "ison";
loadmodule "join";
loadmodule "kick";
loadmodule "links";
loadmodule "list";
loadmodule "lusers";
loadmodule "map";
loadmodule "message";
loadmodule "mode";
loadmodule "motd";
loadmodule "names";
loadmodule "nick";
loadmodule "part";
loadmodule "pass";
loadmodule "pingpong";
loadmodule "protoctl";
loadmodule "quit";
loadmodule "rules";
loadmodule "topic";
loadmodule "user";
loadmodule "userhost";
loadmodule "watch";
loadmodule "whox";
loadmodule "whois";
loadmodule "whowas";

// User commands (EXTENDED)
// These are commands that provide extended functionality.
loadmodule "botmotd";
loadmodule "cap";
loadmodule "cycle";
loadmodule "dccallow";
loadmodule "help";
loadmodule "knock";
loadmodule "lag";
loadmodule "sasl";
loadmodule "setname";
loadmodule "silence";
loadmodule "starttls";
loadmodule "time";
loadmodule "userip";
loadmodule "vhost";

// IRC Operator commands
// Note: several of these like kill are also server-to-server commands
// which are required if you link to other servers.
loadmodule "addmotd";
loadmodule "addomotd";
loadmodule "chghost";
loadmodule "chgident";
loadmodule "chgname";
loadmodule "close";
loadmodule "connect";
loadmodule "squit";
loadmodule "dccdeny";
loadmodule "globops";
loadmodule "kill"; /* also server-to-server */
loadmodule "locops";
loadmodule "mkpasswd";
loadmodule "oper";
loadmodule "opermotd";
loadmodule "sajoin";
loadmodule "samode";
loadmodule "sapart";
loadmodule "sdesc";
loadmodule "sethost";
loadmodule "setident";
loadmodule "stats";
loadmodule "tkl"; /* also server-to-server */
loadmodule "trace";
loadmodule "tsctl";
loadmodule "unsqline";
loadmodule "wallops";
loadmodule "jumpserver";

// Server-to-server commands
// Don't remove these, unless you never link to other servers.
loadmodule "eos";
loadmodule "md";
loadmodule "netinfo";
loadmodule "server";
loadmodule "sjoin";
loadmodule "sqline";
loadmodule "swhois";
loadmodule "umode2";
loadmodule "sinfo";
loadmodule "require-module";

// Services commands
// You could disable these if you don't use Services
// https://www.unrealircd.org/docs/Services
loadmodule "sendsno";
loadmodule "sendumode";
loadmodule "svsjoin";
loadmodule "svskill";
loadmodule "svslusers";
loadmodule "svsmode";
loadmodule "svsmotd";
loadmodule "svsnick";
loadmodule "svsnline";
loadmodule "svsnolag";
loadmodule "svsnoop";
loadmodule "svspart";
loadmodule "svssilence";
loadmodule "svssno";
loadmodule "svswatch";


/*** Channel modes ***/
loadmodule "chanmodes/floodprot"; /* +f */
loadmodule "chanmodes/nocolor"; /* +c */
loadmodule "chanmodes/noctcp"; /* +C */
loadmodule "chanmodes/stripcolor"; /* +S */
loadmodule "chanmodes/issecure"; /* +Z */
loadmodule "chanmodes/permanent"; /* +P */
loadmodule "chanmodes/link"; /* +L */
loadmodule "chanmodes/censor"; /* +G */
loadmodule "chanmodes/delayjoin"; /* +D */
loadmodule "chanmodes/noknock"; /* +K */
loadmodule "chanmodes/noinvite"; /* +V */
loadmodule "chanmodes/operonly"; /* +O */
loadmodule "chanmodes/nonotice"; /* +T */
loadmodule "chanmodes/regonly"; /* +R */
loadmodule "chanmodes/nonickchange"; /* +N */
loadmodule "chanmodes/nokick"; /* +Q */
loadmodule "chanmodes/regonlyspeak"; /* +M */
loadmodule "chanmodes/secureonly"; /* +z */
loadmodule "chanmodes/history"; /* +H */


/*** User modes ***/
loadmodule "usermodes/bot"; /* +B (mark yourself as a bot) */
loadmodule "usermodes/servicebot"; /* +S (service bot) */
loadmodule "usermodes/noctcp"; /* +T (block CTCP's) */
loadmodule "usermodes/censor"; /* +G (censor bad words) */
loadmodule "usermodes/showwhois"; /* +W (show if someone does /WHOIS) */
loadmodule "usermodes/privacy"; /* +p (privacy, hide channels in /WHOIS) */
loadmodule "usermodes/nokick"; /* +q (unkickable oper) */
loadmodule "usermodes/regonlymsg"; /* +R (only registered users may private message you) */
loadmodule "usermodes/secureonlymsg"; /* +Z (only SSL/TLS users may private message you) */
loadmodule "usermodes/privdeaf"; /* +D (don't let other user PM you) */


/*** Server notice masks */
loadmodule "snomasks/dccreject"; /* +D (rejected DCC's) */


/*** Extended Bans ***/
loadmodule "extbans/join"; /* +b ~j (prevent only joins) */
loadmodule "extbans/quiet"; /* +b ~q (prevent only messaging) */
loadmodule "extbans/nickchange"; /* +b ~n (prevent only nick changes) */
loadmodule "extbans/realname"; /* +b ~r (ban by real name) */
loadmodule "extbans/account"; /* +b ~a (ban/exempt if logged in with services account) */
loadmodule "extbans/inchannel"; /* +b ~c (ban/exempt if in channel) */
loadmodule "extbans/operclass"; /* +b ~O (ban/exempt by operclass) */
loadmodule "extbans/certfp"; /* +b ~S (ban/exempt by certfp) */
loadmodule "extbans/textban"; /* +b ~T (censor or block text) */
loadmodule "extbans/msgbypass"; /* +e ~m (bypass message restrictions) */
loadmodule "extbans/timedban"; /* +b ~t (timed bans / temporary bans) */
loadmodule "extbans/partmsg"; /* +b ~p (hide part/quit message) */


/** IRCv3 extensions */
loadmodule "message-tags"; /* add tags to messages, required for various IRCv3 features */
loadmodule "batch"; /* also required for several IRCv3 features */
loadmodule "account-tag"; /* adds services account information to messages */
loadmodule "link-security"; /* link-security announce */
loadmodule "message-ids"; /* adds unique msgid to various messages */
loadmodule "plaintext-policy"; /* plaintext-policy announce */
loadmodule "server-time"; /* adds server timestamp to various messages */
loadmodule "sts"; /* strict transport policy (set::tls::sts-policy) */
loadmodule "echo-message"; /* shows clients if their messages are altered/filtered */


/*** Other ***/
// These are modules that don't fit in any of the previous sections
loadmodule "ident_lookup"; /* Ident lookups if set::options::identd-check is set*/
loadmodule "certfp"; /* SSL/TLS certificate fingerprint in /WHOIS (& more) */
loadmodule "tls_antidos"; /* prevent TLS DoS (renegotiate floods) */
loadmodule "webirc"; /* WEBIRC command. See webirc block. */
loadmodule "blacklist"; /* Blacklist support (DNSBL). See blacklist block. */
loadmodule "jointhrottle"; /* set::anti-flood::join-flood (previously chanmode +j) */
loadmodule "charsys"; /* Provides set::allowed-nickchars (must always be loaded!) */
loadmodule "authprompt"; /* Authentication prompt, see set::authentication-prompt */
loadmodule "history_backend_mem"; /* History storage backend (used by chanmodes/history) */
loadmodule "tkldb"; /* Write TKLines to .db file */
loadmodule "channeldb"; /* Write channel settings to .db file (+P channels only) */
loadmodule "rmtkl"; /* Easily remove *-Lines in bulk with /RMTKL */
loadmodule "restrict-commands"; /* Provides set::restrict-commands settings */
loadmodule "reputation"; /* used by Connthrottle and others, see next */
loadmodule "connthrottle"; /* see https://www.unrealircd.org/docs/Connthrottle */
loadmodule "labeled-response"; /* currently in draft - loaded here to get it tested*/

loadmodule "websocket";

loadmodule "third/authpass";


loadmodule "third/geoip-base";

loadmodule "third/geoip-whois";

loadmodule "third/showwebirc2";

loadmodule "third/traffic";

loadmodule "third/nicksuffix";

blacklist-module "connthrottle";

loadmodule "antimixedutf8";

loadmodule "third/tracetklbug";

syzop

2020-04-12 18:12

administrator   ~0021458

Thank armyn for your help. I know enough now. To anyone else: no need to test anymore, the issue is clear to me.

I am going to mark this issue as private while I further trace it and work on a fix.

syzop

2020-04-18 07:30

administrator   ~0021501

Hi, could you test that with latest upcoming release (5.0.4-rc1) this issue is fixed? Actually I am quite sure about it ;)
To get it you need to use git, so:
git clone https://github.com/unrealircd/unrealircd/ unrealircd-5.0.4-rc1

syzop

2020-04-18 18:56

administrator   ~0021507

Fixed in upcoming 5.0.4 version.

Thanks a lot for your patience, armyn. The issue was quite complex because I could not reproduce it even after hours of trying.
It was only until last week I had an eureka-moment thanks to the tracing module and your testing:D

Issue History

Date Modified Username Field Change
2020-02-12 13:34 armyn New Issue
2020-02-12 19:54 syzop Note Added: 0021325
2020-02-12 19:54 syzop Assigned To => syzop
2020-02-12 19:54 syzop Status new => feedback
2020-02-12 22:14 Lord255 Note Added: 0021327
2020-02-13 18:05 syzop Note Added: 0021329
2020-02-13 18:14 syzop Note Added: 0021330
2020-02-13 18:17 syzop Note Added: 0021331
2020-02-13 18:56 syzop Priority high => normal
2020-02-13 18:56 syzop Note Edited: 0021331
2020-02-13 18:56 syzop Note Edited: 0021331
2020-03-11 13:10 syzop Note Added: 0021361
2020-03-11 13:11 syzop Note Edited: 0021361
2020-03-11 13:23 armyn Note Added: 0021362
2020-03-11 13:33 Lord255 Note Added: 0021363
2020-03-16 22:21 Le_Coyote Note Added: 0021371
2020-03-16 22:55 Lord255 Note Added: 0021372
2020-03-17 00:38 Le_Coyote Note Added: 0021373
2020-03-17 09:37 Lord255 Note Added: 0021374
2020-03-17 13:28 armyn Note Added: 0021375
2020-03-27 09:32 GHF Note Added: 0021388
2020-04-03 09:05 armyn Note Added: 0021397
2020-04-05 18:47 Le_Coyote Note Added: 0021401
2020-04-10 19:41 syzop Note Added: 0021412
2020-04-12 09:12 syzop Note Added: 0021434
2020-04-12 09:18 syzop Note Added: 0021435
2020-04-12 10:05 syzop Note Added: 0021436
2020-04-12 10:07 syzop Note Added: 0021437
2020-04-12 17:54 armyn Note Added: 0021457
2020-04-12 18:12 syzop Note Added: 0021458
2020-04-12 18:13 syzop View Status public => private
2020-04-12 20:34 syzop Status feedback => assigned
2020-04-18 07:29 syzop View Status private => public
2020-04-18 07:30 syzop Note Added: 0021501
2020-04-18 18:56 syzop Status assigned => resolved
2020-04-18 18:56 syzop Resolution open => fixed
2020-04-18 18:56 syzop Fixed in Version => 5.0.4
2020-04-18 18:56 syzop Note Added: 0021507