This updated patch moves VLAN tag decapsulation into if_ethersubr.c and
always uses M_VLANTAG, which is also passed to the upper layer.
Tests with ping:
fxp (no VLAN_HWTAGGING support) OK
msk (VLAN_HWTAGGING enabled) OK
msk (VLAN_HWTAGGING disanabled) FAIL
I am concerned that t
On Sat, Feb 10, 2007 at 06:28:41PM +, Bruce M. Simpson wrote:
> This updated patch moves VLAN tag decapsulation into if_ethersubr.c and
> always uses M_VLANTAG, which is also passed to the upper layer.
>
> Tests with ping:
> fxp (no VLAN_HWTAGGING support) OK
> msk (VLAN_HWTAGGING enable
On Sat, Feb 10, 2007 at 06:28:41PM +, Bruce M. Simpson wrote:
> This updated patch moves VLAN tag decapsulation into if_ethersubr.c and
> always uses M_VLANTAG, which is also passed to the upper layer.
>
> Tests with ping:
> fxp (no VLAN_HWTAGGING support) OK
> msk (VLAN_HWTAGGING
Andrew Thompson wrote:
This is great for the bridge, it has needed to take the vlan tag into
account when deciding to forward or not. Having m_pkthdr.ether_vtag
always set makes this much easier to implement.
In the deleted code M_VLANTAG is cleared but is not done anymore, is
this right?
Pyun YongHyeon wrote:
> Further testing with drivers is needed (I can't be 100% sure it fails
> with msk(4) because something strange is happening when vlan tagging is
> turned off). Perhaps Pyun knows?
>
I guess I've not merged local changes before committing to HEAD.
How about attached
On Wed, Feb 14, 2007 at 07:38:21PM +, Bruce M. Simpson wrote:
> Pyun YongHyeon wrote:
> > > Further testing with drivers is needed (I can't be 100% sure it fails
> > > with msk(4) because something strange is happening when vlan tagging is
> > > turned off). Perhaps Pyun knows?
> > >
>
