linux-kernel - Re: expected behavior of PF_PACKET on NETIF_F_HW_VLAN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1194040328.13340.18.camel@dell>
Date:	Fri, 02 Nov 2007 13:52:08 -0800
From:	"Michael Chan" <mchan@...adcom.com>
To:	"Dave Johnson" <djohnson+linux-kernel@...starentnetworks.com>
cc:	linux-kernel@...r.kernel.org, "netdev" <netdev@...r.kernel.org>,
	bguo@...starentnetworks.com
Subject: Re: expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX
 device?

On Fri, 2007-11-02 at 14:08 -0400, Dave Johnson wrote:

> > 
> > *2:  If chip supports 'ASF', tag is always stripped (see *1 above).
> >      Looks ok if ASF is not supported. 
> 
> Michael,
> 
> These changes seems to cause this issue:
> 
> >  [BNX2]: Fix VLAN on ASF
> >  
> >  Always set up the device to strip incoming VLAN tags when ASF is
> >  enabled. ASF firmware will not parse packets correctly if VLAN tags
> >  are not stripped.
> >  
> >  Signed-off-by: Michael Chan <mchan@...adcom.com>
> >  Signed-off-by: David S. Miller <davem@...emloft.net>
> >  
> >  GIT: e29054f92d7d575631691865c1b95bee5bc974cc
> 
> and
> 
> > ChangeSet@...371.72.2, 2003-12-02 02:34:13-08:00, davem@...s.ninka.net +1 -0
> >   [TG3]: Do not set RX_MODE_KEEP_VLAN_TAG when ASF is enabled.
> 
> 
> Could you elaborate if this is really needed, if so is there some
> workaround that could be done instead?

This is needed for management firmware to work properly.  Management
firmware expects any VLAN tags to be stripped.  Unfortunately, VLAN
stripping cannot be done independently between the driver and the
firmware.  The workaround is to disable management firmware.

> 
> Simply removing the check seemed to work for me, but I'm unsure if
> this is actually a valid thing to do with these MACs.

Most of these on-board devices are shipped with management firmware
enabled.  Removing the check will make the firmware not functional.

We realize this VLAN limitation is causing problems to many users and we
are looking for ways to address it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/