That FAQ is located at

   http://humdi.net/vnstat/FAQ

since that's the easiest way to keep it updated.


----


A snapshot of the FAQ (updated 2.1.2010):


Is there some kind of support forum available?

  The forum is located at http://forums.humdi.net/


I managed to get invalid data into the database after ... playing around with
the system clock / doing some strange network experiments / having the cron
entry not properly configured. Is there a database editor available?

  No.


How should dialup users use vnStat? There's some errors because the interface
isn't available when offline.

  Dialup users should use the daemon for updates. It will take care of
  enabling and disabling the database every time the interface comes and goes.
  It is still also possible to use cron based updates even with a dialup
  interface but that requires proper setup of scripts with enable/disable
  commands every time the status of the interface changes. Example scripts
  can be founds from the pppd directory that came with the source packages.


Does vnStat work for PPPoE users?

  Yes. PPPoE is basically like a dialup connection and it can be monitored
  in the same way as any ppp interface. However, with PPPoE it's usually also
  possible to bring up the LAN interface used for the connection without
  configuring any ip to it. Monitoring that interface is a good alternative
  since it doesn't go down and up when the connection is closed and opened
  again.


How do I stop monitoring an interface?

  Go to the vnStat database directory (default: /var/lib/vnstat) and delete
  the database file named according to the interface you want to stop
  monitoring. The daemon needs to be stopped before this procedure if it's
  being used for updates.


How do I uninstall vnStat?

  You only need to run 'make uninstall' in the directory that comes when the
  .tar.gz is extracted. Just make sure it's the same version you have
  installed. If you've used a binary package included with the distribution
  then refer to intructions provided by the package manager.


What is this KiB/MiB/GiB/TiB thing?

  See http://en.wikipedia.org/wiki/Binary_prefix#Prefixes and UnitMode
  option in the configuration file.


Is the MB value reported by vnStat 10^6 or 2^20 bytes?

  2^20 bytes. The prefix can be configured to show MiB from the configuration
  file instead of MB if that looks better.


What does the 'estimated' value mean?

  The estimated value is an calculated average that tries to predict the total
  traffic for the current day/month based on previous traffic. This estimate
  works fairly well if the monitored interface has constant traffic of the same
  magnitude (like game servers). It can't predic peaks but the accuracy
  usually gets better by the end of the day/month.


Why isn't the estimated value shown with --dumpdb?

  That features only dumps the database and since the estimate is always
  calculated in real time, there's no reason to write it into the database.


How is the estimated value calculated?

  estimate = ( x / y ) * z

    x = traffic so far for the day/month
    y = passed minutes/hours ...
    z = total minutes/hours ...


Why does vnStat show sometimes multiple GB of traffic although my network
connection can't even transfer that much?
     OR
Each update adds the complete amount of traffic and 'vnstat -u -D' claims that
the system has been rebooted between updates.

  That's most likely a broken kernel. Run with --testkernel (version 1.2+ 
  required) and see the result. Also make sure that the maximun bandwidth
  setting has been configured properly according to the network connection.
  See the next question for some explanation about possible kernel problems.


Why is there problems with most 2.4.18 kernels?

  Every current kernel has a btime (boot time) value in /proc/stat that
  indicates when the system was booted. vnStat uses this to know when the
  interface counters in the database should be reseted. Unfortunately, some
  kernels don't keep the btime value static even when the system isn't
  rebooted.


About bug reports

  Any bug report should at least include an explanation about how the bug can
  be reproduced. Having output dumps usually helps and the --dumpdb feature
  should be used if there's some reason to assume the bug has something to do
  with the database. Also include information about the used distribution,
  kernel (uname -a), compiler (gcc --version) and network interface card.
  Read the report again before sending it. :)

