Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Sep 2006 21:54:23 +0200
From:      Andre Oppermann <andre@freebsd.org>
To:        Jung-uk Kim <jkim@FreeBSD.org>
Cc:        Peter Jeremy <peterjeremy@optushome.com.au>, 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:  <45104AEF.10000@freebsd.org>
In-Reply-To: <200609191535.08184.jkim@FreeBSD.org>
References:  <200609182218.k8IMIMUT059300@repoman.freebsd.org> <200609191431.01649.jkim@FreeBSD.org> <20060919190449.GC720@turion.vk2pj.dyndns.org> <200609191535.08184.jkim@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

-- 
Andre




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45104AEF.10000>