genius3000
commented
5 years ago This is unfortunately some current limitations to the module. It's not actually "kicking in"; the "disconnecting" messages are a best guess. The way the blocking works without bans is that no connect class will match (if configured to do so). This causes a normal disconnect of "denied by configuration". These disconnects and unfortunately others are shown as possible disconnects from this module. Note: some things, like self quitting and socket level errors are already skipped. More note: in writing this, I wonder if there's a reason I don't check for the quit reason to match "denied by configuration".
The "missing" values listed are just for informational purposes and only say that prior to disconnecting (for any reason) they were missing that thing. It doesn't mean the module blocked them for those reasons.
I'll do some testing with a few ideas and see if I can quiet down the messages for banned, etc. disconnects.
P.S. if you unload the module and the user from the second example connects fine, implying the module was blocking them...it's a whole different problem to look into.
It appears that the block messages still kick in, even if a user is caught by a Z-Line. Also it seems that by default, all connect class options are enabled.
Redacted example: [17:32] -irc.aerospacechat.com- *** XLINE: HOPM added permanent Z-line for: You have a host listed in the DroneBL. For more information, visit http://dronebl.org/lookup_branded?ip=&network=AeroSpaceChat
[17:32] -irc.aerospacechat.com- *** CONN_REQUIRE: Disconnecting unregistered user PowerfulUser!KiwiIRC@ () [[https://kiwiirc.com] Development release] on port 6697 that was missing: VERSION REPLY
The issue is stating they had no CTCP VERSION reply, when KiwiIRC does always give it out. It appears that m_conn_require "kicks in" even if a user is banned, is this intentional and could it be altered to not "kick in" under these circumstances?
Another example: [19:34] -irc.aerospacechat.com- *** CONN_REQUIRE: Disconnecting unregistered user 179AAABCM!unknown@ () [] on port 6697 that was missing: CAP, VERSION REPLY
No connect class is set to have any of the respective requirements on, and they are said to default off. Are they defaulting to on after all or am I misunderstanding something?
Regards,
Koragg