View Issue Details

IDProjectCategoryView StatusLast Update
0006117unrealircdpublic2022-05-27 18:12
ReporterValware Assigned To 
PrioritynormalSeveritytrivialReproducibilityhave not tried
Status feedbackResolutionopen 
Product Version6.0.4-rc1 
Summary0006117: Floodmode seems to be acting strangely
DescriptionAnother oper on my network rejoined a channel this morning after pinging out and this happened.

[07:36:00] * Sysop_NiteStorm-ssa (SysopNiteS@netadmin.afnet.us) Quit (irc.afnet.us ssa.afnet.us)
[07:36:08] * Sysop_WARDEN (SysopNiteS@netadmin.afnet.us) Quit (Ping timeout: 180 seconds)
[07:36:28] * ~Sysop_NiteStorm (SysopNiteS@valware.uk) Quit (Ping timeout: 180 seconds)
[07:36:43] * Sysop_NiteStorm (SysopNiteS@Clk-BF9CDA14.dsl.airstreamcomm.net) has joined #PossumsOnly
[07:36:43] -ssa.afnet.us:%#PossumsOnly- *** Channel joinflood detected (limit is 5 per 6 seconds), setting mode +i
[07:36:43] * ssa.afnet.us sets mode: +i
[07:37:41] * ssa.afnet.us sets mode: -i
Steps To ReproduceHave not tried
TagsNo tags attached.
3rd party modules

Activities

syzop

2022-05-27 17:13

administrator   ~0022532

It seems a server had a netsplit too, right? So it timed out and reconnected?
ssa.afnet.us is the one who set the mode, what server is that.. the one who squit and reconnected... or ?
Any special users in that channel? Eg several services bots?
And, just to be sure, you didn't do any crazy 'git pull' updates where you only did '/REHASH' instead of restart (on ssa.afnet.us)? In which case the entire heap memory could be corrupt. Just checking... :D

Valware

2022-05-27 17:29

reporter   ~0022533

ssa.afnet.us was the one who ping timed out and reconnected, who set the mode. Then, looking closer, that is the only UnrealIRCd-6.0.3 in the networks link between me and it.
I am using 6.0.4-rc, services is connected to a 6.0.4-rc the server between me and ssa.afnet.us is using 6.0.4-git (and did no funny uplink and rehashing), and then the server which set the mode seems to be 6.0.3
Yes there is one ChanServ in the channel.

syzop

2022-05-27 17:40

administrator   ~0022535

Last edited: 2022-05-27 17:40

Hmm not sure what happened... I was thinking maybe it saw a lot of joins in a short period due to the netburst. But I specifically designed it that when two servers link, the clients who join because of the syncing / netburst are not counted for +f so +f cannot be triggered. This is done using the "EOS" feature, only after EOS people are counted for +f.

syzop

2022-05-27 17:45

administrator   ~0022536

Hmmm no I have no idea. If you got time, feel free to play around a bit more and see if you can trigger it.
If there is anything then it is likely not related to 6.0.3<->6.0.4 as there is only 1 line difference in src/modules/chanmodes/floodprot.c and that is related to timed bans, not this.

Valware

2022-05-27 18:11

reporter   ~0022538

I've tried reproducing it from squits and joins and doesn't seem to be triggering it, which leaves me to believe the mode was set as a result of multiple people locally rejoining a channel after the server had restarted/started being contactable again, which closes this as a bug.

Valware

2022-05-27 18:12

reporter   ~0022539

I would just hazard a guess that there was also a netjoin at this time and some of that joinflood activity wasn't displayed fully, so perhaps we only saw the one more person joining and the floodmode kicking in =]

Issue History

Date Modified Username Field Change
2022-05-27 16:44 Valware New Issue
2022-05-27 17:13 syzop Note Added: 0022532
2022-05-27 17:13 syzop Status new => feedback
2022-05-27 17:29 Valware Note Added: 0022533
2022-05-27 17:40 syzop Note Added: 0022535
2022-05-27 17:40 syzop Note Edited: 0022535
2022-05-27 17:45 syzop Note Added: 0022536
2022-05-27 18:11 Valware Note Added: 0022538
2022-05-27 18:12 Valware Note Added: 0022539