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) {
		case ETHERTYPE_IP:
			return (gen_cmp(off_linktype, BPF_W,
					(bpf_int32)htonl(AF_INET)));
			break;

On tcpdump.org, I found the following commit:

http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/gencode.c?r1=1.138&r2=1.139

It seems bpf does comparisons in network order always, hence the htonl
above, and there is now support (not in netbsd, but in tcpdump.org
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 <gdt@ir.bbn.com>