Subject: Re: tcpflow vs. lo0 on 2.0_BETA
To: Curt Sampson <>
From: Greg Troxel <>
List: tech-net
Date: 08/19/2004 08:24:50
  tcpflow[2618]: warning: received non-AF_INET null frame (type 33554432)

Note that ntohl(33554432) == 2.

I always had the impression that the AF word was in host byte order.
A quick scan of sys/net/* for DLT_NULL and looking at how the header
is consed onto the mbuf before bpf_mtap shows that at least most of
them do it in host byte order.

But, it seems broken for DLT_NULL to have host ordering, since that
would seem to break reading a stored trace on another endian machine.

In /usr/src/lib/libpcap/gencode.c, I found

	case DLT_NULL:
		switch (proto) {
			return (gen_cmp(off_linktype, BPF_W,

On, I found the following commit:

It seems bpf does comparisons in network order always, hence the htonl
above, and there is now support (not in netbsd, but in
pcap) to swap values from cross-endian save files.

So, I'd say tcpflow is incorrect and should expect host order, and
byteswapped if (p->sf.rfile != NULL && p->sf.swapped).

        Greg Troxel <>