From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 20:41:20 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30D1016A41C for ; Mon, 6 Jun 2005 20:41:20 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from grunt14.ihug.co.nz (grunt14.ihug.co.nz [203.109.254.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E24743D48 for ; Mon, 6 Jun 2005 20:41:18 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from 203-173-150-184.bliink.ihug.co.nz (lycra.luckie.org.nz) [203.173.150.184] by grunt14.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1DfOPJ-0000Lo-00; Tue, 07 Jun 2005 08:41:13 +1200 Received: from mjl by lycra.luckie.org.nz with local (Exim 4.51 (FreeBSD)) id 1DfOOK-000Nna-Cd; Tue, 07 Jun 2005 08:40:12 +1200 Date: Tue, 7 Jun 2005 08:40:12 +1200 From: Matthew Luckie To: Bruce M Simpson Message-ID: <20050606204008.GA91353@lycra.luckie.org.nz> References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> <20050606120851.GD734@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050606120851.GD734@empiric.icir.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2005 20:41:20 -0000 > > If I was to pursue this, would someone on this list consider committing the > > work to current? > ... > > + case DLT_NULL: > > + sockp->sa_family = AF_UNSPEC; > > + if(strcmp(ifp->if_name, "tun") == 0) > > + hlen = sizeof(int); > > + else > > + hlen = 0; > > + break; > > Maybe this won't work if an instance of tun is renamed? I'd compare "tun" > with ifp->if_dname (driver name) to be on the safe side. right. although the patch was against 4.11 which does not have if_dname. does 4.11 support renaming interfaces? it doesn't appear to. i wasn't really suggesting that we'd add a series of strcmp to see which driver corresponds to the DLT_NULL, just that if if_tun was handled specially then bpf writes would work correctly on it. > Another way of dealing with this would be to ask the tcpdump.org guys to > define a DLT type for tun interfaces, rather than special-casing it for > DLT_NULL. is there a good reason why _all_ DLT_NULL bpf devices could not simply have writes supported? the user space application would pass the address family in the first 4 bytes of the packet; this is currently done anyway for if_disc, if_loop, if_tun, if_faith, and ng_iface. ip_carp could get bpf writes for free with AF_UNSPEC added to the carp_looutput() switch statement. [mjl@mylar sys]$ egrep -r 'bpfattach.+DLT_NULL' * dev/iicbus/if_ic.c: bpfattach(ifp, DLT_NULL, ICHDRLEN); dev/ppbus/if_plip.c: bpfattach(ifp, DLT_NULL, sizeof(u_int32_t)); i4b/driver/i4b_ipr.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); net/if_disc.c: bpfattach(ifp, DLT_NULL, sizeof(u_int)); net/if_faith.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); net/if_gif.c: bpfattach(&sc->gif_if, DLT_NULL, sizeof(u_int)); net/if_gre.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int32_t)); net/if_loop.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); net/if_stf.c: bpfattach(ifp, DLT_NULL, sizeof(u_int)); net/if_tun.c: bpfattach(ifp, DLT_NULL, sizeof(u_int)); netgraph/ng_iface.c: bpfattach(ifp, DLT_NULL, sizeof(u_int)); netgraph/ng_sppp.c: bpfattach (&pp->pp_if, DLT_NULL, sizeof(u_int)); netinet/ip_carp.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int32_t)); Matthew