I don't have any results yet, but this is how I'm measuring it using Debian Linux.

Network traffic in the Linux kernel is managed through the tool iptables. Conveniently there are completely separate tables for ipv4 and ipv6 so I don't have to do anything to separate those. There are several chains which packets traverse depending on where they came from, where they're going and whether or not they're being routed on behalf another computer.

The chains of interest are INPUT, FORWARD and OUTPUT on the default table. INPUT receives all packets destined for this particular computer, FORWARD receives all packets which are being ferried on behalf of other computers (in my case, sharing Internet access with NAT) and OUTPUT receives all packets being sent from this particular computer, not on behalf of anyone else. By default all of these will simply allow the packets to pass unmolested.

What I've done is create four custom chains: ipv4_input_ppp0, ipv4_forward_in, ipv4_forward_out and ipv4_output_ppp0. They don't actually do anything, which permits the packets to continue onward, but iptables will keep track of how much traffic travels through each rule, both as a number of packets and in bytes.

Here is some output from "iptables -x -n -v -L" with these chains set up:

Chain INPUT (policy ACCEPT 617 packets, 92499 bytes)
pkts      bytes target     prot opt in     out     source               destination
41     5511 ipv4_input_ppp0  all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT 46173 packets, 28090499 bytes)
pkts      bytes target     prot opt in     out     source               destination
21742 10919366 ipv4_forward_out  all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0
24431 17171133 ipv4_forward_in  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 487 packets, 113453 bytes)
pkts      bytes target     prot opt in     out     source               destination
61     4783 ipv4_output_ppp0  all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0

The rules are set up to use iptables' built in filtering capability. The ipv4_input_ppp0 rule will only collect packets which have an "in" interface of "ppp0". This means that packets from me sshing to my router from my LAN will not be counted. ipv4_output_ppp0 is handled the same way.

Similarly the destination interface is used to differentiate between incoming and outgoing traffic which is being forwarded by my router doing its router job, leading to counts in ipv4_forward_in and ipv4_forward_out.

This means we have direct byte counts which we can pull out of iptables and add together to get total incoming and outgoing ipv4 traffic. To make the information easier to process the counts can be zeroed at any time by running "iptables -Z".

The ipv6 setup is exactly the same except you use the tool ip6tables instead.

Here's my configuration for datalogging. I use the following in my firewall script which is run on boot to set up the chains and rules:


iptables -F
iptables -X

iptables -N ipv4_input_ppp0
iptables -N ipv4_forward_in
iptables -N ipv4_forward_out
iptables -N ipv4_output_ppp0

iptables -A INPUT -i ppp0 -j ipv4_input_ppp0
iptables -A FORWARD -o ppp0 -j ipv4_forward_out
iptables -A FORWARD -o eth0 -j ipv4_forward_in
iptables -A OUTPUT -o ppp0 -j ipv4_output_ppp0

iptables -Z

ip6tables -F
ip6tables -X

ip6tables -N ipv6_input_ppp0
ip6tables -N ipv6_forward_out
ip6tables -N ipv6_forward_in
ip6tables -N ipv6_output_ppp0

ip6tables -A INPUT -i ppp0 -j ipv6_input_ppp0
ip6tables -A FORWARD -o eth0 -j ipv6_forward_in
ip6tables -A FORWARD -o ppp0 -j ipv6_forward_out
ip6tables -A OUTPUT -o ppp0 -j ipv6_output_ppp0

ip6tables -Z

Then I run this script every day at midnight from root's crontab:


#!/bin/bash

ipv4_input_ppp0=`iptables -x -n -v -L | grep 'ipv4_input_ppp0' | grep all | sed -e "s/\s\+/\t/g" | cut -f 3`
ipv4_forward_in=`iptables -x -n -v -L | grep 'ipv4_forward_in' | grep all | sed -e "s/\s\+/\t/g" | cut -f 3`
ipv4_forward_out=`iptables -x -n -v -L | grep 'ipv4_forward_out' | grep all | sed -e "s/\s\+/\t/g" | cut -f 3`
ipv4_output_ppp0=`iptables -x -n -v -L | grep 'ipv4_output_ppp0' | grep all | sed -e "s/\s\+/\t/g" | cut -f 3`

iptables -Z

ipv6_input_ppp0=`ip6tables -x -n -v -L | grep 'ipv6_input_ppp0' | grep all | sed -e "s/\s\+/\t/g" | cut -f 3`
ipv6_forward_in=`ip6tables -x -n -v -L | grep 'ipv6_forward_in' | grep all | sed -e "s/\s\+/\t/g" | cut -f 3`
ipv6_forward_out=`ip6tables -x -n -v -L | grep 'ipv6_forward_out' | grep all | sed -e "s/\s\+/\t/g" | cut -f 3`
ipv6_output_ppp0=`ip6tables -x -n -v -L | grep 'ipv6_output_ppp0' | grep all | sed -e "s/\s\+/\t/g" | cut -f 3`

ip6tables -Z

ipv4_in=`echo "$ipv4_input_ppp0 + $ipv4_forward_in" | bc`
ipv4_out=`echo "$ipv4_forward_out + $ipv4_output_ppp0" | bc`
ipv6_in=`echo "$ipv6_input_ppp0 + $ipv6_forward_in" | bc`
ipv6_out=`echo "$ipv6_forward_out + $ipv6_output_ppp0" | bc`

echo "$ipv4_in $ipv4_out $ipv6_in $ipv6_out" >> /var/log/traffic/ip

Here's a bit of odd behaviour from the BSD machine shown from /var/log/messages:

Nov 20 03:08:33 cogline slattach[644]: SIGHUP on /dev/ttyd0 (sl-1); exiting

This occurs when I run slattach -s 115200 /dev/ttyd0 with nothing attached to the port, or when the other computer is connected and has been running slattach for "a while" (a minute or two?). Debian slattach has no difficulty running with the serial port in any condition, and if it's started reasonably soon before the BSD slattach, everything is fine.

Unfortunately this kind of problem makes it difficult to set up computers that will automatically negotiate a SLIP connection when they first turn on. I configured the BSD system to run slattach and the required ifconfig command on boot and it never works.

Normally SIGHUP is used to indicate that the carrier has dropped and a redial is necessary. The BSD slattach code reveals that the above message is simply what the SIGHUP handler does when no redial command is set, presumably before the interface has finished initialising because the "unit" is still "sl-1" instead of "sl0". I'm using a null modem cable so it makes sense that the carrier will go down when nothing is attached, but that doesn't explain the failure when both are running for a while.

Curious. Stay tuned, I might learn something.

Here's how I've set it up on my home Debian server so that it will provide IPv6 addresses to my home network:

1. Add +ipv6 to /etc/ppp/peers/dsl-provider
2. I had to change the username in dsl-provider and in /etc/ppp/chap-secrets to use a different hostname, as this is how Internode knows you want to connect to the IPv6 trial server.
3. Start the DSL connection with "pon dsl-provider", resulting in a connection ppp0 which has both an IPv4 internet address, and a local fe80:: IPv6 address
4. Ensure eth0 has a local IPv6 address too, using ifconfig. I was messing about and lost it, and got it back by resetting with ifdown eth0; ifup eth0
5. Now to get a real IPv6 prefix you need an IPv6 DHCP client. At Internode's suggestion I installed the WIDE client (package wide-dhcpv6-client in Debian). The given working configuration for a PPP connection ppp0 and local ethernet connection eth0 is placed in /etc/wide-dhcpv6/dhcp6c.conf as follows:
   interface ppp0 {
send ia-pd 0;
script "/etc/wide-dhcpv6/dhcp6c-script";
};
id-assoc pd {
prefix-interface eth0 {
sla-id 0;
sla-len 4;
};
};
6. When you install the WIDE DHCPv6 client it starts automatically, with an non-useful config. Restart it with invoke-rc.d wide-dhcpv6-client restart. Hopefully now an "ifconfig" will show that you have successfully attached a 2001:: prefix address to your eth0 interface.
7. Add a default route -- this doesn't happen automatically. Run the command:
   route --inet6 add default dev ppp0
   This will add a default route through the gateway on your PPP connection.
8. At this point there is working IPv6 connectivity on the local machine. It can be tested with "ping6 ipv6.google.com":
   # ping6 ipv6.google.com
PING ipv6.google.com(tx-in-x68.1e100.net) 56 data bytes
64 bytes from tx-in-x68.1e100.net: icmp_seq=1 ttl=56 time=171 ms
64 bytes from tx-in-x68.1e100.net: icmp_seq=2 ttl=56 time=172 ms
9. To set up advertising of addresses and routing I referred to Martin Krafft's excellent IPv6 with Debian documentation. In summary, the configuration I had to do was to set /proc/sys/net/ipv6/conf/all/forwarding to 1, which can be made permanent by setting it in /etc/sysctl.conf, and to set up radvd.
10. radvd (which is also the name of the package) will provide IPv6 addresses from the allocated /64 prefix to hosts on the local network. Install the package. I set my /etc/radvd.conf to the following, which uses the prefix I was allocated, as found from ifconfig:
    interface eth0
{
AdvSendAdvert on;
AdvLinkMTU 1280;
prefix 2001:44b8:7c90:be0::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
11. Now other machines with IPv6 support which are connected via the eth0 interface should be allocated an address and will be able to access the IPv6 Internet too.

I have a fun ISP who gives me toys to play with. :)

One common example of this in geek circles is LaTeX, the typesetting software distribution. There seems to be a gene in some people that gives them the warm fuzzies as soon as they find a cool piece of software which few others are using, especially if there's some slightly cryptic-looking syntax to prevent others from getting in on the action.

LaTeX is good, yes. It is not, however, a justification for the destruction of all word processors ever created and branding their users as people who work in dumb ways. Nor will it kill you to use a word processor if you have to, or if, heaven forbid, it's more convenient in a given situation. Your pathetic cries of inferiority only cause the attention you yearn for to be directed at somebody else.

Linux is a bigger example. If you like Linux, that's fine by me, whatever your reasons. I use it and love it too. But the moment you tell me that you cannot do your work on a Windows computer, it's not Windows' inferiority that's the problem. It's your inability to adjust, your lack of general technical expertise and your ego trying not to get crushed by the fact that your reputation for only using cool non-mainstream software will be sundered.

So what's acceptable here? I think it's pretty simple:

• Don't associate yourself with your tools (conversely, don't judge others by their tools)
• Use the right tool for the job!

We all like to poke fun at companies or their software which we don't like. I'm not complaining about that. A certain amount of banter and bitchiness is healthy and fun. But for goodness' sake, please don't get personal. It is the software which has strengths and weaknesses. Not you. What defines you as an effective computer person is being able to evaluate competing software products or technologies fairly and accurately, and being able to get the most of out each one.

Having done that you can use what you like, but don't come to me for help when you've hamstrung yourself with your own obsessions.

Today I'm going to present a possible solution to the first complaint: poor file format support. The accepted way to extend your OS X machine to play (oddball?) formats like FLAC seems to be to install the Xiph components for Quicktime. In my experience, this will usually convince Quicktime to play most things. Getting iTunes to look at the songs and store them in your library is another matter entirely. The best success I ever had with this method was getting about 1/3 of my considerable collection of FLACs to import.

Let's fix things up with a little bit of Firefly. No, not the unbelievably awesome Joss Whedon show (blast you, Fox!) but the also rather awesome Firefly Media Server, formerly known as mt-daapd. I last played with this project a couple of years ago and it took some tinkering to make it work. There's been a bit of work done since then and now the latest build is in the Debian stable repository, so it's dead simple to set this up now.

"Debian? Isn't this a problem with iTunes on OS X?" you might be wondering to yourself now. Yes. You're right. Allow me to present the recipe for this particular solution:

iTunes Make Support Go-Go

Ingredients

• One computer running Mac OS X with iTunes
• One computer running Debian Linux
• Your music in any of normal formats: MP3, OGG, FLAC, WMA, etc. stored on the Linux computer
• Firefly Media Server
• A LAN connecting to the two computers

1. Install the package with aptitude install mt-daapd
2. Edit /etc/mt-daapd.conf and set admin_pw to an admin password, mp3_dir to where your music is (with a trailing slash) and add any file extensions to the list of those it will serve. In my case, I had to add wma. You can also change the name of your server if you like.
3. /etc/init.d/mt-daapd start
4. Head to iTunes on the mac and notice either the name you set or "Firefly ..." appears in the shared libraries list.
5. Play your music. Observe how you can play songs in all formats regardless of whether iTunes supports them directly.

The magic at work here is that Firefly will use ffmpeg to transcode any songs not natively supported by iTunes on the fly to uncompressed wave format.

One extra advantage is that you no longer need to use all the hard drive space on your mac, which can be handy if it's a laptop. One disadvantage is that you can only listen to your music when you're on the same LAN as the Linux box. Perhaps you should have thought about that before you paid the Mac tax and expected them to support your open formats properly. *sigh*

(serves as many as your Firefly server has the bandwidth to serve)