summaryrefslogtreecommitdiffstats
path: root/database/sqlite/sql-schema.sql
diff options
context:
space:
mode:
authorDavid Sommerseth <dazo@users.sourceforge.net>2008-09-26 07:09:26 +0200
committerDavid Sommerseth <dazo@users.sourceforge.net>2008-09-26 07:09:26 +0200
commit372ef358481bab5dcb3d4b34fab07409b935d485 (patch)
tree8e633919e7182c7365a38ce867c671119ac159a5 /database/sqlite/sql-schema.sql
parent757f8229d3407e96962eeb5573ca0024d97abd31 (diff)
downloadeurephia-372ef358481bab5dcb3d4b34fab07409b935d485.tar.gz
eurephia-372ef358481bab5dcb3d4b34fab07409b935d485.tar.xz
eurephia-372ef358481bab5dcb3d4b34fab07409b935d485.zip
BUGFIX: Made sure that eDBget_sessionkey_seed(...) only returns a sessionkey for sessions which is in open status (sessionstatus is 1 or 2).
When a client does a disconnect for session_A, the status of the session is 3, as logged out but not yet deleted. In this status, the session is not deleted, nor is the record in openvpn_sessionkeys for that sessions's sessionseed. If the client then does a new reconnection (session_B) before the session is deleted, it will get the sessionkey for the session which was just logged out, session_A's sessionkey. When OpenVPN then calls the learn_address function to delete the session_A, that session will be closed. This results in that session_B will then do not match any open sessions at all, since session_A and session_B shared the sessionseed to a sessionkey. By changing the eDBget_sessionkey_seed(...) to check that the sessionstatus is 1 or 2 (open session statuses), it should generate a new sessionkey for the session_B, since no sessionkey would be returned for that sessionseed. The destruction of the session (done via eurephia_learn_address(...)) will still work, since this function uses the MAC address of the client and not the sessionseed.
Diffstat (limited to 'database/sqlite/sql-schema.sql')
0 files changed, 0 insertions, 0 deletions