Anope Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001618Anope Stable (2.0.x series)[All Projects] Generalpublic2014-10-10 01:212014-10-15 01:01
Reporteralefburzmali 
Assigned ToAdam 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Summary0001618: DEFCON_REDUCED_SESSION breaks the session counts
DescriptionWhen DEFCON_REDUCED_SESSION is in action, the session count is no longer correctly recorded. It allows to completely bypass both the DEFCON reduced session limit and the default session limit.

With the default setting "sessionlimit = 2":
- 3 users can connect from the same IP without being killed, the SESSION VIEW command reports 3 users from that IP
- the 4th to connect is killed, the SESSION VIEW command reports only 2 users from that IP (3 are still connected)
- the 4th user can reconnect without being killed, the SESSION VIEW command reports only 3 users from that IP (4 are connected)
- can be repeated with as many users as wanted

Ater that, if DEFCON is disabled, the session count for that IP is still messed up until all the users from that IP have disconnected.
Steps To ReproduceHave 4 users connect from the same IP while DEFCON_REDUCED_SESSION with sessionlimit = 2 is in action. Only one user is killed, SESSION VIEW reports only 2 sessions from that IP and the fourth user can reconnect without being killed.

Have a 5th user to connect from the same IP, he is killed but he can reconnect without being killed. Repeat as much as you want.
Additional InformationWith the following (default) settings:
- os_session defaultsessionlimit = 3
- os_defcon sessionlimit = 2
- os_defcon level3 has reducedsessions


Without defcon:
- user AA connects from 192.0.2.1
- user BB connects from 192.0.2.1
- user CC connects from 192.0.2.1
- /os session view 192.0.2.1 -> 3 sessions
- user DD connects from 192.0.2.1, he is killed by OperServ (Session limit exceeded)
- /os session view 192.0.2.1 -> 3 sessions


With defcon:
- /os defcon 3
  ...
  * Use the reduced session limit of 2
- user AA connects from 192.0.2.1
- user BB connects from 192.0.2.1
- user CC connects from 192.0.2.1. CC is not killed even though he should be
- /os session view 192.0.2.1 -> 3 sessions
- user DD connects from 192.0.2.1. DD is killed by OperServ (Defcon session limit exceeded)
- /os session view 192.0.2.1 -> **2** sessions instead of 3 (AA, BB and CC)
- user DD reconnects from 192.0.2.1. He is not killed.
- /os session view 192.0.2.1 -> **3** sessions instead of 4 (AA, BB, CC and DD)
- user EE connects from 192.0.2.1, is killed by OperServ (Defcon session limit exceeded)
- user EE reconnects from 192.0.2.1. He is not killed.
- /os session view 192.0.2.1 -> **3** sessions instead of 5
- /os defcon 5
- /os session view 192.0.2.1 -> still 3 sessions instead of 5
- DD quits
- /os session view 192.0.2.1 -> 2 sessions instead of 4
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0006665)
Adam (administrator)
2014-10-15 01:01

This was due to module event prioritization being fubard. os_defcon relies on accessing os_sessions's session data after it has already processed.
(0006664)
alefburzmali (reporter)
2014-10-13 17:46

DEFCON_NO_NEW_CLIENTS (which kills the new clients) has the same effect. Session count is one less than what it should be after the client is killed.

DEFCON_AKILL_NEW_CLIENTS glines the host, so the session count for that IP is set to 0 as all the clients are disconnected.

- Issue History
Date Modified Username Field Change
2014-10-10 01:21 alefburzmali New Issue
2014-10-13 17:46 alefburzmali Note Added: 0006664
2014-10-15 01:01 Adam Note Added: 0006665
2014-10-15 01:01 Adam Status new => resolved
2014-10-15 01:01 Adam Resolution open => fixed
2014-10-15 01:01 Adam Assigned To => Adam


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker