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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
