View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006117||unreal||ircd||public||2022-05-27 16:44||2022-05-27 18:12|
|Priority||normal||Severity||trivial||Reproducibility||have not tried|
|Summary||0006117: Floodmode seems to be acting strangely|
|Description||Another 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 Reproduce||Have not tried|
|Tags||No tags attached.|
|3rd party modules|
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
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.
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.
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.
||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.|
||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 =]|
|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|