View Issue Details

IDProjectCategoryView StatusLast Update
0005566unrealircdpublic2020-03-27 09:32
Reporterarmyn Assigned Tosyzop  
PrioritynormalSeveritymajorReproducibilitysometimes
Status feedbackResolutionopen 
OSCentOS  
Product Version5.0.3.1 
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

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.

syzop

2020-03-11 13:10

administrator   ~0021361

Last edited: 2020-03-11 13:11

View 2 revisions

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.

Mr_Smoke

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)

Mr_Smoke

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

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
2020-03-11 13:10 syzop Note Added: 0021361
2020-03-11 13:11 syzop Note Edited: 0021361 View Revisions
2020-03-11 13:23 armyn Note Added: 0021362
2020-03-11 13:33 Lord255 Note Added: 0021363
2020-03-16 22:21 Mr_Smoke Note Added: 0021371
2020-03-16 22:55 Lord255 Note Added: 0021372
2020-03-17 00:38 Mr_Smoke 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