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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
