cvs commit: src/sys/dev/bge if_bge.c
jkim at FreeBSD.org
Tue Sep 19 13:42:47 PDT 2006
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. :-(
More information about the cvs-src