bpf writes on tun device

[Matthew Luckie]

> I'd be wary of changing the definition of DLT_NULL however -- it literally
> means 'there's nothing here apart from raw data', and changing this notion
> would mean that we have to change it everywhere, including bpf clients,
> because the change being proposed would make DLT_NULL mean 'there's a 32-bit
> integer in front of everything else which is raw data', which is something
> else.

this was the behaviour expected of most DLT_NULL bpf devices already 
(passing a 32bit int when writing).  It is important to note that the 
behaviour of BPF writers does not change in these cases, and my patch is 
merely a bug fix.

the other interface output functions probably did not work with BPF, as 
bpfwrite was passing the sockaddr dst structure with dst->sa_family == 
AF_UNPSEC, which would have caused most of the rest to return 
EAFNOTSUPPORTED or whatever.

I think the exceptions to this are if_stf and if_ic, but i'm not sure 
how many bpf writers in the wild this patch would affect; i am not aware 
how many people actually use these interfaces.

> I'd suggest a name like DLT_PSEUDO might be better -- it may be helpful to
> get review for the change from the NetBSD and OpenBSD guys too, as well as
> the tcpdump.org guys.

i will pursue the review with other BSD systems.  this is something 
important to me, and something i'd like to see fixed.  but my argument 
is going to be for DLT_NULL for the reasons above.

> Looking at style, it might be better if the driver(s) were changed to
> explicitly use a 32-bit wide int type such as u_int32_t for the address
> family header field in their bpfattach() calls. ICHDRLEN is odd man out,
> but it is #define'd to be the same thing; I would update it there also.

the last parameter to bpfattach specifies the size of the psuedo header 
attached on bpf rx; that's a separate thing to fix, but one that does 
need to be made self-consistent.

> It helps my dayjob because we're currently looking at what it would take to
> integrate a code drop of the IS-IS routing protocol by one of our students --
> unfortunately to remain backwards compatible with existing IS-IS deployments
> out there, we need to be able to speak link layer IS-IS as well as IPv4
> encapsulated IS-IS.
> 
> Of course to do this, we need bpf write support for the appropriate link
> layers. The more link layers we have support for bpf writes, particularly
> across the software loopback and tunnel type links, the better it is for
> testing and integration, as well as running IS-IS directly over a VPN
> on FreeBSD.

My situation is related to work i'm doing with ports/net/scamper, which 
needs to have some probe packets passed without interference by the IP 
stack to the wire.

I'll see if I can get consensus with NetBSD / OpenBSD / Darwin / 
tcpdump-workers.

Thanks.

Matthew