Date: Tue, 19 Sep 2006 16:42:25 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Andre Oppermann <andre@FreeBSD.org> Cc: src-committers@FreeBSD.org, cvs-all@FreeBSD.org, John Baldwin <jhb@FreeBSD.org>, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/bge if_bge.c Message-ID: <200609191642.27659.jkim@FreeBSD.org> In-Reply-To: <45104AEF.10000@freebsd.org> References: <200609182218.k8IMIMUT059300@repoman.freebsd.org> <200609191535.08184.jkim@FreeBSD.org> <45104AEF.10000@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 19 September 2006 03:54 pm, Andre Oppermann wrote: > Jung-uk Kim wrote: > > On Tuesday 19 September 2006 03:04 pm, Peter Jeremy wrote: > >> On Tue, 2006-Sep-19 14:30:59 -0400, Jung-uk Kim wrote: > >>> On Tuesday 19 September 2006 01:52 pm, John Baldwin wrote: > >>>> Which I'm about to kill hopefully. Please let's fix this the > >>>> right way and not hack it any further. > >>> > >>> Sure, no problem. But I don't think we can DTRT on -STABLE > >>> without breaking API. Can we? > >> > >> I've had a quick look into this problem because I extensively > >> use VLANs on a bge and discovered that I no longer have VLAN tag > >> details (which makes packet tracing a nuisance). > >> > >> As far as I can see, there is nothing preventing bpf_tap() and > >> bpf_mtap2() being doctored to undo the VLAN detagging so that > >> bpf_filter() is passed a mbuf chain that looks like an 802.1Q > >> ethernet frame: Dummy up an mbuf (as bpf_mtap2() does) that > >> contains the MAC addresses from the incoming data followed by > >> the 802.1Q packet type and tag information, with m_next pointing > >> to the byte after the MAC addresses in the original data. > > > > Why don't we just fake it up from ether_input() and pass it to > > BPF_MTAP() instead of 'teaching' bpf? I think it is more logical > > thing to do. > > Then it would be kinda pointless to have the hardware remove it in > the first place. Actually that was exactly why I tried to disable hardware VLAN tagging when there is bpf peer (in this kludge, promiscuous mode instead) but I wasn't able to find better way. :-( Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609191642.27659.jkim>