Anope Bug Tracker - Anope Stable (2.0.x series)
View Issue Details
0001618Anope Stable (2.0.x series)[All Projects] Generalpublic2014-10-10 01:212014-10-15 01:01
alefburzmali 
Adam 
normalmajoralways
resolvedfixed 
0001618: DEFCON_REDUCED_SESSION breaks the session counts
When 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.
Have 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.
With 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
No tags attached.
Issue History
2014-10-10 01:21alefburzmaliNew Issue
2014-10-13 17:46alefburzmaliNote Added: 0006664
2014-10-15 01:01AdamNote Added: 0006665
2014-10-15 01:01AdamStatusnew => resolved
2014-10-15 01:01AdamResolutionopen => fixed
2014-10-15 01:01AdamAssigned To => Adam

Notes
(0006665)
Adam   
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   
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.