Dear Maintainer,

   * What led up to the situation?

     I wanted to see my server's DNS queries.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

     I've run dnstop with: sudo dnstop <my-interface> on the
     machine running the DNS server. Then I issued some (successful)
     DNS queries to this machine.

   * What was the outcome of this action?

     The DNS queries were not shown in the interface.

   * What outcome did you expect instead?

     I would like to see DNS queries listed in the interface
     as they hit the server.

The problem seems to persist with the newer version (dnstop-20140915.tar.gz)
which I compiled from the source. The problem *does not* happen if
I run dnstop from a tcpdump capture (saved with -w <filename>).

Cheers,
Tomasz

Control: severity -1 grave
I've analyzed my problem and found what follows.

ANALYSIS
=========

First, only the QUERY packets are missing in dnstop, the RESPONSE
packets show (mostly) fine with dns -Q -R <interface>. I say "mostly"
because they can be still lost if there is too much traffic coming to
the card.

Second, the use of "pcap_fileno" is incorrect, it seems that
"pcap_get_selectable_fd" should be used instead. I'm not sure it
changes anything in practice, though.

Third, "pcap_select" in the code is called with 1s of timeout: for
reasons that are unclear to me, this makes the pcap library drop the
packets randomly (verified with "pcap_stats") and these drops are the
reason for this bug. Strangely, making the timeout smaller (say 50ms)
makes the problem go away. Removing the use of "pcap_select"
altogether works as well, however this causes dnstop to eat 100% of
ther CPU due to "pcap_setnonblock".

SOLUTIONS
===========

(1) Changing the "pcap_select" timeout to something like 50ms works
    for me, but this is hardly a real solution.

(2) Removing "pcap_setnonblock" and "pcap_select" from the code solves
    the problem as well. In this case we should probably also increase
    "to_ms" in "pcap_open_live" to something bigger than 1ms (I've set
    it to 50ms - a tolerable time for an interface to freeze).

(3) Increasing the buffer size for the capture could work as well, but
    I haven't tried it.

===========

My preferred solution is (2) and I attach a proof-of-concept
patch. The reason for having (1) in the upstream is a support for
MacOSX which we don't really care about in Debian. However, we have
non-Linux ports (FreeBSD officialy and hurd) and I have no idea
whether (2) will work for them.  For example, while researching this,
I found that there is no promise that "pcap_dispatch" will respect the
timeout given in "pcap_open_live" (it may actually block).

Personally I think this bug is RC (the package does not work
out of the box) and I'm bumping the severity.

Cheers,
Tomasz

I believe this isn't a RC bug, as it not seem to fall in any of these
categories:

==============
* makes unrelated software on the system (or the whole system)
 break
* causes serious data loss
* introduces a security hole on systems where you install the
 packages
  (these issues are "critical" severity)

* makes the package in question unusable or mostly so
* causes data loss
* introduces a security hole allowing access to the accounts
 of users who use the package
  (these issues are "grave" severity)

* in the maintainer's opinion, makes the package unsuitable
 for release
  (these issues are "serious" severity)
===============

(package can still be used with tcpdump data)

more info: https://release.debian.org/jessie/rc_policy.txt