Date: Wed, 08 Jun 2005 07:54:26 +1200 From: Matthew Luckie <mjl@luckie.org.nz> To: Bruce M Simpson <bms@spc.org> Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device Message-ID: <42A5FB72.4010603@luckie.org.nz> In-Reply-To: <20050607112340.GC812@empiric.icir.org> References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> <20050606120851.GD734@empiric.icir.org> <20050606204008.GA91353@lycra.luckie.org.nz> <20050607101927.GA99034@lycra.luckie.org.nz> <20050607112340.GC812@empiric.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42A5FB72.4010603>