Packet capture woes with libpcap on Ubuntu Trusty and Debian Jessie

Usually when you’re using libpcap to capture network traffic, your chief worry will be whether or not your application will keep up with the flow of traffic.

Today, though, I’ve stubbed my toe on a problem with traffic that’s too slow. It happens with both Ubuntu Trusty and Debian Jessie. If there’s a gap between packets of more than about 50 milliseconds, the first packet to arrive after the gap will be dropped and you’ll never see it. I was capturing DNS queries and responses, and found that with a query rate of under 20 queries per second you start dropping queries. By the time you’re down to 15 queries per second, nearly every query is dropped.

After spotting that tcpdump doesn’t have this problem, and much experimentation later, it’s not quite as simple as that. Whether or not you drop packets depends on the libpcap API you are using. If you’re using pcap_loop() to capture packets, you can stop worrying. This works properly. I guess that tcpdump is using pcap_loop() to capture packets and that’s why it works.

If, on the other hand, you’re using pcap_dispatch() or pcap_next_ex(), as the documentation urges you to do, than you’re doomed. This is regardless of whether you are using blocking or non-blocking mode.

So, what can you do? Your choices are limited.

  1. Switch your application to using pcap_loop(). If you were using non-blocking mode with either pcap_dispatch() or pcap_next_ex(), this will be non-trivial, as pcap_loop() doesn’t observe non-blocking, but always blocks. It won’t be straightforward either if you’re using pcap_next_ex() in your own loop.
  2. Upgrade. The problem is fixed if you upgrade Ubuntu to Xenial. I also found the problem apparently fixed by updating Jessie to the 4.7.0 kernel in Debian Backports.

Comparing drill output

I wanted to compare the output of multiple drill queries. After a bit of trial error, I came up with this sed to remove the parts of drlll’s output that change from query to query.

drill | grep -v "Query time" | grep -v WHEN 
        | sed 's/t[[:digit:]]{1,}t|,sid.{1,}$//'

FreeBSD with new xorg 1.12.X

A while ago I switched my FreeBSD desktop to the new xorg 1.12.X. In ports this requires adding WITH_NEW_XORG=yes to /etc/make.conf.

I only found out today that for packages you need to add a file called /etc/pkg/FreeBSD-new-xorg.conf containing:

FreeBSD_new_xorg: {
 url: "pkg+${ABI}/new_xorg",
 mirror_type: "srv",
 signature_type: "fingerprints",
 fingerprints: "/usr/share/keys/pkg",
 enabled: yes

Re-installing everything to see if it is more stable

Patch to APC PowerChute Network Shutdown for Ubuntu

The following patch fixes the install script for Ubuntu 13.04

--- 2013-09-25 16:07:54.772107691 +0000
+++ 2013-09-26 12:05:46.214115186 +0000
@@ -1,4 +1,4 @@
 # PowerChute Network Shutdown v.3.0.1
@@ -22,6 +22,7 @@
@@ -288,6 +289,11 @@
 # We're a Linux derivative, decide which one.
 if [ -f /etc/vima-release ] || [ -f /etc/vma-release ]; then
+ elif [ -x /usr/bin/lsb_release ]; then
+ /usr/bin/lsb_release -i | grep Ubuntu > /dev/null
+ if [ $? -eq 0 ]; then
+ fi
 grep XenServer /etc/redhat-release > /dev/null 2>&1
 if [ $? -eq 0 ]; then
@@ -368,6 +374,11 @@
+ STARTUP=/etc/init.d/PowerChute
+ PCBE_STARTUP=/etc/init.d/PBEAgent
+ PCS_STARTUP=/etc/init.d/pcs
+ ;;
@@ -563,6 +574,9 @@
 /etc/rc.d/init.d/PowerChute stop
+ /etc/init.d/PowerChute stop
+ ;;
 /etc/rc2.d/S99PowerChute stop
@@ -977,6 +991,10 @@
 cp Linux/ notifier
 cp Linux/ shutdown
+ cp Linux/ notifier
+ cp Linux/ shutdown
+ ;;
 cp Solaris/ notifier
 cp Solaris/ shutdown
@@ -1057,6 +1075,14 @@
 rm -f /etc/rc.d/rc4.d/*99PowerChute
 rm -f /etc/rc.d/rc5.d/*99PowerChute
 rm -f /etc/rc.d/rc6.d/*99PowerChute
+ elif [ $OS = "$LINUX_UBUNTU" ] ; then
+ rm -f /etc/rc0.d/*99PowerChute
+ rm -f /etc/rc1.d/*99PowerChute
+ rm -f /etc/rc2.d/*99PowerChute
+ rm -f /etc/rc3.d/*99PowerChute
+ rm -f /etc/rc4.d/*99PowerChute
+ rm -f /etc/rc5.d/*99PowerChute
+ rm -f /etc/rc6.d/*99PowerChute
@@ -1069,6 +1095,14 @@
 elif [ -f /sbin/chkconfig ]; then
 chkconfig --add PowerChute
 chkconfig PowerChute on
+ elif [ $OS = "$LINUX_UBUNTU" ] ; then
+ ln -s /etc/init.d/PowerChute /etc/rc0.d/K99PowerChute
+ ln -s /etc/init.d/PowerChute /etc/rc1.d/K99PowerChute
+ ln -s /etc/init.d/PowerChute /etc/rc2.d/S99PowerChute
+ ln -s /etc/init.d/PowerChute /etc/rc3.d/S99PowerChute
+ ln -s /etc/init.d/PowerChute /etc/rc4.d/S99PowerChute
+ ln -s /etc/init.d/PowerChute /etc/rc5.d/S99PowerChute
+ ln -s /etc/init.d/PowerChute /etc/rc6.d/K99PowerChute
 ln -s /etc/rc.d/init.d/PowerChute /etc/rc.d/rc0.d/K99PowerChute
 ln -s /etc/rc.d/init.d/PowerChute /etc/rc.d/rc1.d/K99PowerChute
@@ -1120,6 +1154,14 @@
 if [ -f /sbin/chkconfig ]; then
 chkconfig PowerChute off
 chkconfig --del PowerChute
+ elif [ $OS = "$LINUX_UBUNTU" ] ; then
+ rm -f /etc/rc0.d/*99PowerChute
+ rm -f /etc/rc1.d/*99PowerChute
+ rm -f /etc/rc2.d/*99PowerChute
+ rm -f /etc/rc3.d/*99PowerChute
+ rm -f /etc/rc4.d/*99PowerChute
+ rm -f /etc/rc5.d/*99PowerChute
+ rm -f /etc/rc6.d/*99PowerChute
 rm -f /etc/rc.d/rc1.d/K99PowerChute
 rm -f /etc/rc.d/rc2.d/S99PowerChute

Juniper SRX mucking with DNS

I was getting some strange DNS answers on the servers in a trust zone on my SRX. All the servers are statically NAT’d to external IP’s and run their own caching resolvers but when I tried to query for the servers A RR I kept getting the internal IP address. No name server either internal or external was serving that A RR. Eventually I realised that it was the SRX changing the answer section of the DNS response. I don’t know if it is on by default, or if I switched it on by mistake but it was the DNS Application Layer Gateway (ALG) trying to help by making use of what it knew about the static NATs. Switching DNS ALG off solved the issue. For a detailed description of what the ALG does see the Junos OS Security Configuration Guide.

FreeBSD svn and passwords

I have been getting the message about storing un-encrypted svn passwords for ages on FreeBSD and Ubuntu. I finally thought I would look into how you store encrypted passwords.

ATTENTION! Your password for authentication realm:
<> Sinodun Projects Subversion Repository
can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in

Lots of goggling later the best I could find was an article about gnome-keyring-daemon and subversion which mentions the need for A quick search found this was missing on my system. A moment of dumbness later I remembered make config and found the port config option needed.


re-installing the port unfortunately broke svn with the following message:

svn: E175002: OPTIONS of '': SSL handshake failed: SSL disabled due to library version mismatch (

Thanks to this that was quickly fixed by rebuilding neon:

sudo portupgrade -f neon*

Flush DNS cache on Ubuntu

This weekend I came across several pages on the web suggesting ways to flush the DNS cache on Ubuntu. I will not point to the offending pages here but they are easy to find with Google. Most of them are wrong in several ways.

  1. Ubuntu doesn’t install a DNS cache by default
  2. Most of the pages say something along the lines of to flush the DNS cache you need to restart the nscd deamon.
  3. See 1
  4. As a result of 1 – They tell you to install nscd so that you can then restart nscd!
  5. I redirect your attention to issue 1.

If you really want a local cache then I would suggest installing unbound which will work better and give you DNSSEC as well.

Ubuntu, efi booting and Nvidia

I have just set up a Ubuntu 12.10 workstation on a new motherboard (ASUS P8Z77 WS) which has efi instead of the traditional BIOS and installed a NVidia Quadro 600 graphics card.

You can ignore the efi and install your OS as standard if you want. The efi provides BIOS compatibility. However, that would be too easy!

efi booting

Getting the Ubuntu DVD to install in efi booting mode is easy. With the DVD in the drive the efi sees both a efi and regular version of the DVD. Just set the boot order to start with the efi version of the DVD, you get a text display with several options including one to install Ubuntu. At the end of the install Grub2 is installed and configured to support efi booting. You may need to update the efi firmware to get the newly installed Ubuntu to boot.

Nvidia drivers

There is some mention on the web that the nvidia drivers may not work with efi booting. If you rely on Ubuntu to do the correct thing when you apt-get install nvidia-current then you might think that is correct. However, after a bit of investigation, they work fine for me. The major problem is that the Nouveau display driver is getting control of the card before the nvidia one does. You can see which driver is loaded by using

lspci -v

You will get output like this (This example is after fixing things, the “Kernel driver in use” line shows nouveau by default)

04:00.0 VGA compatible controller: NVIDIA Corporation GF108GL [Quadro 600] (rev a1) (prog-if 00 [VGA controller])
 Subsystem: NVIDIA Corporation Device 0835
 Flags: bus master, fast devsel, latency 0, IRQ 16
 Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
 Memory at e8000000 (64-bit, prefetchable) [size=128M]
 Memory at f0000000 (64-bit, prefetchable) [size=32M]
 I/O ports at e000 [size=128]
 [virtual] Expansion ROM at f7000000 [disabled] [size=512K]
 Capabilities: <access denied>
 Kernel driver in use: nvidia
 Kernel modules: nvidia, nouveau, nvidiafb

You can remove the offending Xorg driver like this:

sudo apt-get --purge remove xserver-xorg-video-nouveau

However that doesn’t actually remove the nouveau kernel module. A quick fix is to:

sudo rm -rf /lib/modules/3.5.0-18-generic/kernel/drivers/gpu/drm/nouveau

and then rebuild the initramfs

sudo update-initramfs -u

This final command is important as it removes the offending driver from the boot ram disk.