View Issue Details

IDProjectCategoryView StatusLast Update
0005566unrealircdpublic2020-02-14 16:50
ReporterarmynAssigned Tosyzop 
Status feedbackResolutionopen 
PlatformOSCentOS OS Version7.7
Product Version5.0.3.1 
Target VersionFixed in Version 
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 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 (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



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.


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.


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.


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.


2020-02-13 18:17

administrator   ~0021331

Last edited: 2020-02-13 18:56

View 3 revisions

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.

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 View Revisions
2020-02-13 18:56 syzop Note Edited: 0021331 View Revisions