[solved] - Traffic Graphs: Cannot get data about interface [2.0.2]
-
Cannot get data about interface ste0
This is on the traffic graphs and on the dashboard. I have two WANs and two LANs.
Sometimes, if i delete history in chrome, the traffic graphs will work okay for 5 or less minutes, then the problem occurs.
Sometimes, one of the interfaces shows the problem, sometimes all four of the interfaces.i tried reinstalling the packages: squid, squidguard and lightsquid and also ln -s /usr/local/bin/perl5.12.4 /usr/bin/perl to no avail.
This only happened when i updated from 2.0.1 to 2.0.2-RELEASE (i386) built on Fri Dec 7 16:30:38 EST 2012.It only occurs on Chrome but not on IE.
I dunno with FF.
When using chrome, i need to delete the history like every 5 minutes to refresh the graphs, but in IE it automatically reconnects the graph even it shows Server Error for a few seconds. In 2.0.1, everything was fine, been using Chrome 24/7 for the traffic graphs with no problem.Thanks in advance for any help.
-
I am experiencing the same issue.
2.0.2-RELEASE (amd64) built on Fri Dec 7 22:39:16 EST 2012 FreeBSD 8.1-RELEASE-p13
This is a clean install with my previous 2.0.1 settings imported in.
The issue is random and sporadic. I have four interfaces on the dashboard that I am monitoring. The WAN interface stopped graphing after a few minutes and then the WAN2 interface stopped graphing several minutes later.
I haven't tried other browsers or clearing the cache. A scree refresh or logging in/out does not resolve the problem.
-
I attached my dashboard, one from Chrome and the other one from IE.
Both captured with a few seconds difference.
I dunno why chrome just show the errors in 2.0.2.
It was very fine before the update.
Yeah, I know most will say that it's just a small issue and just use IE.
But I prefer to use chrome as my browser.Btw, the proxy state under lightsquid does not auto refresh after the update, neither in chrome nor in IE.
-
I can confirm this as well. If I switch the physical interface it works for awhile but then eventually gets in this same state.
-
I can confirm this as well. If I switch the physical interface it works for awhile but then eventually gets in this same state.
what browser are you using? I can only see this in Google Chrome.
-
I can confirm this as well. If I switch the physical interface it works for awhile but then eventually gets in this same state.
what browser are you using? I can only see this in Google Chrome.
Sorry I thought it was implied. I'm seeing it in Chrome as well. Works fine in IE.
-
I am using Safari 6.0.2 in Mac OS X 10.8.2.
![Screen Shot 2012-12-26 at 10.05.03 PM.png](/public/imported_attachments/1/Screen Shot 2012-12-26 at 10.05.03 PM.png)
![Screen Shot 2012-12-26 at 10.05.03 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2012-12-26 at 10.05.03 PM.png_thumb) -
@slampert: they[developers] might advise us to use IE ;D
@tim.mcmanus: i believe you have no IE in Mac, so i don't know what they will advise you. ;D -
Uh, yeah we'd never in a million years recommend anyone use IE for any purpose whatsoever. A significant portion of us use Chrome, if there were a universal problem we'd have seen it long ago.
JimP testing this earlier, couldn't replicate. I've had all the graphs on 2 different systems going for upwards of a half hour, 0 problems, they're still updating as I'm writing this.
There was only one small change to any of the files related, this here:
https://github.com/bsdperimeter/pfsense/commit/c93b202d75e3df1aecbb25587e1a225a05fbcc9cto fix IE being retarded. Given the scope and relevance of that change, it's improbable that's related. Maybe if you all have stale caches in your browser that Jim and I don't have. You can try going back to the previous revision of that file from here:
https://raw.github.com/bsdperimeter/pfsense/86e1405de40ca1ab1d7ce6726e1181b9ea32f359/usr/local/www/status_graph.phpand see what happens.
Going to have to get some feedback from those who are seeing the issue, since it's not an issue for any of us.
-
You guys have the Widescreen package installed by chance? Wondering if it's breaking stuff as it commonly does since it overwrites base system files.
Chrome is the #1 browser of visitors to this site, 42% of visits in the last month. Thousands of systems have been upgraded to 2.0.2 already. The fact that 3 people are reporting an issue lends to something unusual like a package being the case. There would be a massively long thread by now if it didn't work in Chrome in general.
-
@cmb:
You guys have the Widescreen package installed by chance? Wondering if it's breaking stuff as it commonly does since it overwrites base system files.
Chrome is the #1 browser of visitors to this site, 42% of visits in the last month. Thousands of systems have been upgraded to 2.0.2 already. The fact that 3 people are reporting an issue lends to something unusual like a package being the case. There would be a massively long thread by now if it didn't work in Chrome in general.
Packages: squid, squidguard, lightsquid, imspector, mailreport,sarg and vnstat2 only.
At first i was afraid that it is only my setup that was messed up so i didn't post the problem, but when 2 users confirmed my problem, it was a "sigh of relief" knowing that i didn't do something stupid during the upgrade or on my setup.I will try to revert to the previous revision of the php file (but i don't know how, so i will still search the forum for how to upload that one ???)
Thanks for your attention sir.Update: I tried reverting the php file under /usr/local/www/status_graph.php and same problem happened.
-
Behaviour depends on version of Chrome?
-
I tried the old status_graph.php to no avail, but clearing my cache fixes it for awhile. I turned off all my chrome extensions to rule that out as a cause. I have only two packages installed, mtr-nox11 and nut. My chrome version is 23.0.1271.97 m.
-
I have nmap and pfBlocker installed, but no other packages.
I'm also working on a clean install of 2.0.2, however I did import my previous settings.
I'll try emptying my browser cache to see if it resolve it when it happens again.
EDIT: Just lost one graph after keeping the Dashboard window open for 15 minutes. Emptying the cache fixed the issue.
EDIT AGAIN: Lost another graph, a different one this time and not sure how long it took to fail, but emptying Safari's cache and reloading the Dashboard page resolved the issue.
-
24 hours and counting, 8 live graphs on dashboard, all still working in Chrome. Latest version on Windows in that instance. Works on my Mac too though I haven't had them going on it for as long.
-
When the graph failed I got the following error when I had Safari in developer mode.
Server error 500.
See enclosed screen shot.
EDIT: Added a second image from an hour later.
![Screen Shot 2012-12-28 at 2.16.20 AM.png](/public/imported_attachments/1/Screen Shot 2012-12-28 at 2.16.20 AM.png)
![Screen Shot 2012-12-28 at 2.16.20 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2012-12-28 at 2.16.20 AM.png_thumb)
![Screen Shot 2012-12-28 at 3.11.18 AM.png](/public/imported_attachments/1/Screen Shot 2012-12-28 at 3.11.18 AM.png)
![Screen Shot 2012-12-28 at 3.11.18 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2012-12-28 at 3.11.18 AM.png_thumb) -
is there anything in /tmp/php_errors.txt?
-
-
Another interesting observation: I disabled the caching in Safari and got three 500 errors. However, since caching was disabled in the browser, the graphs never stopped working.
![Screen Shot 2012-12-28 at 2.20.58 PM.png](/public/imported_attachments/1/Screen Shot 2012-12-28 at 2.20.58 PM.png)
![Screen Shot 2012-12-28 at 2.20.58 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2012-12-28 at 2.20.58 PM.png_thumb) -
I remembered one other change, lighttpd was upgraded. Its upgrades have broken things in weird ways in the past, wonder if something in it is somehow causing 500s that only a seemingly very small % of users see. Anyone capable of extracting just the lighttpd files from the 2.0.1-Full-Update tgz and replacing those files, that would be a good test to see if that makes it go away. Just the lighttpd binary alone may be adequate.