Traffic Graphs: Cannot get data about interface

  • Hi,

    in our pfsense 2.3.2-RELEASE on APU2, the Traffic Graphs widget on the Dashboard after several hours loses graphing, instead displaying the error

    Cannot get data about interface
    ```followed by the interface name, like f.e. igb0.
    In the system log we see nothing out of the ordinary.
    This seems a recurrence of the problem discussed in [](, although that has been declared solved in 2013 with v2.0.3.
    An suggestions, what to do or where to look further? Some specific log or filter expression?

  • Hi,

    Clarification: we used Firefox v47.0.1, will test with IE v11.0.9600.18500 on Win8.1pro.

    Mostly graphing in FF stopped after running overnight. To cite from measures taken in the old thread, we got these results:

    • Reloading the Dashboard page, i.e. repeating the Login to it, resolved the issue for the nonce.

    • /tmp/php_errors.txt does not contain any data.

    • Package manager reports no additional packages installed.

    In other news, apparently nginx is now the main web server; a possible relevant error appears in /var/log/nginx-errors.log:```
    2016/10/04 09:10:26 [error] 16350#100143: *13129 upstream timed out (60: Operation timed out) while reading response header from upstream, client:, server: , request: "GET /ifstats.php?if=igb0 HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "", referrer: ""

  • Hi,

    well, IE v11 didn't fare any better than Firefox, after running over the weekend, both complained of that same error.

    Will still check with Chrome-based Vivaldi, as well.

    Meanwhile, on reload all browsers showed

    502 Bad Gateway

    Under /var/log, neither system.log nor nginx-error.log  had entries pertaining to that.

    A reboot fixed this, so we're now looking at Vivaldi for the time being.

  • So,

    Vivaldi, and thus implicated, Chrome, didn't fare any better. Same old soup, "Cannot get data about interface" on any interface graph we'd care to look at. Seems browser independent, now.

    That timeout in accessing fastcgi://unix:/var/run/php-fpm.socket (in the error log from Oct. 28) looks weird though, now doesn't it?