Bug #8116
closed
status_graph.php: Premature session termination when monitoring live traffic graphs
100%
Description
During around 5 minutes RRD webpage shows the traffic data, then it shows a blank screen, and when refresh, logon to webgui is required again.
on 2.4 RRD webpage was showing data for a much longer time.
Files
Updated by Jimmy Meskens almost 7 years ago
- File session.jpg session.jpg added
Vladimir Lind wrote:
During around 5 minutes RRD webpage shows the traffic data, then it shows a "SESSION_TIMEOUT", and when refresh, logon to webgui is required again.
This problem started with version 2.4.x, with version 2.3.x this worked fine.
We need to have a permanent webpage with traffic graph open to monitor.
See screenshot about the timeout.
Updated by Jim Pingle almost 7 years ago
Is there a session timeout logged in the main system log when this happens?
Updated by Jim Pingle almost 7 years ago
- Status changed from New to Feedback
This does not appear to be a general issue. I've left that page open for nearly an hour now with the same settings you have and it hasn't timed out on a couple systems here.
That SESSION_TIMEOUT ajax message can only appear in a few cases:
1. The session actually timed out, which would be logged in the main system log
2. The user manually logged out, which would be logged in the main system log
3. There was a login failure from the same browser (e.g. someone manually submitted bad data to the login form), which would be logged in the main system log
4. There was a protocol mismatch (http to https change or vice versa)
5. The session data is missing, for example if something wiped out the PHP session files in /tmp/sess_*, if the browser's cookie data is reset, or something in between interrupted or changed that data (e.g. a proxy between the client and the GUI)
Until we know if any log messages accompany the issue it's difficult to narrow that down.
Updated by Jimmy Meskens almost 7 years ago
No there is no timout logged in the log, I can only see when I reconnect again.
Updated by Jimmy Meskens almost 7 years ago
It worked fine with version 2.3.x but I have the problem since 2.4.x
Updated by Jim Pingle almost 7 years ago
If there is no log message at all, then 5 in that list is the most likely issue. But I've gone through the base system code and all of the packages and I don't see anything in either place that would wipe out those files in /tmp or otherwise kill sessions silently.
Updated by Jimmy Meskens almost 7 years ago
About nr. 5 ( Proxy ), Squid is configured in PFSENSE.
But it is weird that all worked fine with version 2.3.X, and once upgrading to 2.4.x the problems started. I have another machine running with 2.3.3 and this is working fine, no timout at all.
Updated by Jim Pingle almost 7 years ago
Does your connection to the GUI go through the proxy? Usually that would not be the case if the proxy is on the firewall, the traffic to the firewall itself wouldn't use the proxy unless it was manually configured in the browser without a bypass.
The version difference may be related but there were many changes from 2.3.x to 2.4.x so that doesn't help narrow it down at all.
Updated by Jimmy Meskens almost 7 years ago
No the connection does not go through the Proxy.
Since all was working fine with 2.3.3, it definitely is something with version 2.4.1 and 2.4.2 in my opinion...
There should be something that disconnect the GUI after some time. I tried the "session timeout" in user manager settings set to zero, as I found this on the net, but also no difference..
In any way, If you cannot help, no problem, then I try bit of playing around, and if I cannot find, install back to 2.3.3, where it all worked fine...
Updated by Jim Pingle almost 7 years ago
As I stated above, if it was the timeout, there would be a log message. There is no log message, so it is not actually a timeout but the session being cleared somehow or rendered invalid by something in your setup/configuration.
There were hundreds of changes between 2.3.x and 2.4.x so saying it's related to the upgrade is vastly oversimplifying it and ignoring all of the research we've already done here. It is not that simple, and all signs point to it being something unique to you and not a general problem. We'll keep looking into it, but without more data to go on I'm not sure what we'll be able to uncover.
Updated by Jimmy Meskens almost 7 years ago
Thanks for your help, and I fully understand it is not that simple :)..
As a test, I tried to run same on another machine on another location/network with 2.4.2 and same result, so very weird :)..
In anyway, I try to find out more also from my side, and will try to disable some packages ( like squid, squidguard, snort, etc.. ) to see if I can find the root cause at some point...
When I find something, I will update you here.
Thanks, and please do know that I appreciate the work you guys are doing :)..
I will also setup a new machine with 2.4.2 with no packages and basic setup, to see if that goes OK.
Updated by Jimmy Meskens almost 7 years ago
I tried everything I can, but I cannot find why the GUI gives a "session_Timeout" after around 10 minutes.
I tried :
1) A PFSENSE on another location with 2.4.2
2) Installing a new PFSENSE, without any special package like Squid, Squidquard, Snort, etc... so just a basic config.
3) Other browser, different PC, etc....
4) Installing a new device with 2.3.3, and then all work fine. As from version 2.4.X, the problems started.
5) Checking each setting in PFSENSE, but cannot find anything and also logs don't show timeout.
6) Contacted some other person with verion 2.4.2, and asked them to do same. They confirmed me that they have same issue.
I am not sure what can cause the issue, and we have a paid support, so I would appreciate to use this support to help us finding the issue. If it can help, remote connection is possible.
Regards
Jimmy
Updated by Chris Macmahon almost 7 years ago
We got access to the machine this morning, and tested for ~30 mins could not duplicate the results. This seems local to the client accessing pfSense.
Please attempt a hard refresh, ctrl - F5, if that does not work delete all the cookies/cache on the machine and try again.
Updated by Jim Pingle almost 7 years ago
- Subject changed from webgui autologout after 5 min idle on 2.4.2 to status_graph.php: Premature session termination when monitoring live traffic graphs
- Status changed from Feedback to Confirmed
- Target version set to 2.4.3
- Affected Architecture All added
- Affected Architecture deleted (
)
We have confirmed this does happen in some cases but we have not yet definitively narrowed down a specific cause or environmental trigger(s).
A few facts we have determined:
- It appears to be isolated to only status_graph.php
- The session is not actually timing out, there is no log message indicating the session timeout code was triggered
- The SESSION_TIMEOUT Error from the AJAX script merely indicates that the request was unable to locate the session (e.g. user not logged in)
- The session data file in /tmp/sess* appears to be wiped out (0 bytes after the error appears), logging back in produces a new session
- Times vary but generally the problem appears to hit around 25 minutes (Though some have seen it around 20, others around 30)
- There do not appear to be any specific packages in common between systems that have the issue
- There are no cron or minicron jobs that would trigger at the times the session disappears
- At the time the new session expires, the old/invalid 0 byte session file for the previous session in /tmp/sess* disappears
- The session still fails with the calls to updateBandwidth() / bandwidth_by_ip.php disabled so it does not appear to be specific to that page/code.
Updated by Jim Pingle almost 7 years ago
One more thing, the graph call to ifstats.php that happens when the session fails contains the login page, but still offers the same session ID in the response cookie.
Updated by Jim Pingle almost 7 years ago
Changing auth_check.inc to guiconfig.inc in ifstats.php and bandwidth_by_ip.php seems to correct the behavior. With guiconfig.inc the session has remained active for over 2 hours.
Updated by Jim Pingle almost 7 years ago
- Assignee set to Jim Pingle
It appears that without a session_commit() the session appears to be stale to PHP's session garbage collection. I've pushed a fix to ensure a commit happens which solves the timeout issue.
Updated by Jim Pingle almost 7 years ago
- Status changed from Confirmed to Feedback
- % Done changed from 0 to 100
Applied in changeset fe7c4634fd49ae02298f41bc2b6a8030fa99ac07.
Updated by Jim Pingle almost 7 years ago
- Target version changed from 2.4.3 to 2.4.2-p1
Updated by Jim Pingle almost 7 years ago
- Status changed from Feedback to Resolved