On 2018/05/08 16:11, Elad Nachman wrote:
> Currently running:
> ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100
>
> On eth0=stmmac succeeds, but the end result is that the vlan device gets
> proto 802.1q instead of proto 802.1ad and drops the received packet. Without
> the patch pa
Currently running:
ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100
On eth0=stmmac succeeds, but the end result is that the vlan device gets proto
802.1q instead of proto 802.1ad and drops the received packet. Without the
patch packets gets dropped for a seemingly "correct" 802.1ad
On 2018/05/08 15:01, Elad Nachman wrote:
> stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before
> calling napi_gro_receive().
>
> The function assumes VLAN tagged frames are always tagged with 802.1Q
> protocol,
> and assigns ETH_P_8021Q to the skb by hard-coding the paramete
stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before
calling napi_gro_receive().
The function assumes VLAN tagged frames are always tagged with 802.1Q protocol,
and assigns ETH_P_8021Q to the skb by hard-coding the parameter on call to
__vlan_hwaccel_put_tag() .
This causes
