You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of my networks has a few users who are on unstable connections, so their client keeps reconnecting and timing out during SASL authentication. This is causing our services log channel to be full of LOGIN (session timed out) messages from SaslServ, and there are about 20 of those messages for every successful LOGIN message. Additionally, the timeout happens during connection registration, so my ircd (charybdis) doesn't even log what IP they're using so I can impose a D-Line, but I don't think it's fair to do that. As a network admin, I don't have the ability to fix these clients. The log message also does not provide any value because it's not a successful authentication or even a completed but failed attempt, which could be a sign of a user's account being attacked.
Suggested fix: remove the below part of sasl_session_destroy or provide a configuration option to disable this message without disabling the other SaslServ messages:
Original commit by @lstarnes1024, edited by @aaronmdjones to further
remove the flag that it depended on, now that it has no use. Shuffling
the other flag up after it is okay because the only user of this flag
is saslserv/main, and reloading that will reload all other saslserv
modules anyway, so there is no ABI concern.
cf. #701
cf. 2a446dd628ae9bf133b8Closes#701Closes#702
One of my networks has a few users who are on unstable connections, so their client keeps reconnecting and timing out during SASL authentication. This is causing our services log channel to be full of
LOGIN (session timed out)
messages from SaslServ, and there are about 20 of those messages for every successfulLOGIN
message. Additionally, the timeout happens during connection registration, so my ircd (charybdis) doesn't even log what IP they're using so I can impose a D-Line, but I don't think it's fair to do that. As a network admin, I don't have the ability to fix these clients. The log message also does not provide any value because it's not a successful authentication or even a completed but failed attempt, which could be a sign of a user's account being attacked.Suggested fix: remove the below part of
sasl_session_destroy
or provide a configuration option to disable this message without disabling the other SaslServ messages:The text was updated successfully, but these errors were encountered: