Ryota Ozaki <ozaki.ryota%gmail.com@localhost> writes: > NetBSD can't do this because a loopback interface > registers itself to bpf as DLT_NULL and bpf treats > packets being sent over the interface as AF_UNSPEC. > Packets of AF_UNSPEC are just dropped by loopback > interfaces. > > FreeBSD and OpenBSD enable to do that by letting users > prepend a protocol family to a sending data. bpf (or if_loop) > extracts it and handles the packet as an extracted protocol > family. The following patch follows them (the implementation > is inspired by OpenBSD). > > http://www.netbsd.org/~ozaki-r/loop-bpf.patch > > The patch changes if_loop to register itself to bpf > as DLT_LOOP and bpf to handle a prepending protocol > family on bpf_write if a sender interface is DLT_LOOP. I am surprised that there is not already a DLT_foo that already has this concept, an AF word followed by data. But I guess every interface already has a more-specific format. Looking at if_tun.c, I see DLT_NULL. This should have the same ability to write. I have forgotten the details of how tun encodes AF when transmitting, but I know you can have v4 or v6 inside, and tcpdump works now. so obviously I must be missing something. My suggestion is to look at the rest of the drivers that register DLT_NULL and see if they are amenable to the same fix, and choose a new DLT_SOMETHING that accomodates the broader situation. I am not demanding that you add features to the rest of the drivers. I am only asking that you think about the architectural issue of how the rest of them would be updated, so we don't end up with DLT_LOOP, DLT_TUN, and so on, where they all do almost the same thing, when they could be the same. I don't really have an opinion on host vs network for AF, but I think your choice of aligning with FreeBSD is reasonable.
Attachment:
signature.asc
Description: PGP signature