Hi, I have several X710-DA4 that I purchased at different times, and some of them I was able to grab the latest firmware (5.05) and upgrade them. nvmupdate64e and ethool show this on the good ones:

driver: i40e

version: 1.6.42

firmware-version: 5.05 0x8000289d 1.1568.0

bus-info: 0000:85:00.2

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

WARNING: To avoid damage to your device, do not stop the update or reboot or power off the system during this update.

Inventory in progress. Please wait [.........*]

Num Description                               Ver. DevId S:B    Status

=== ======================================== ===== ===== ====== ===============

01) Intel(R) Ethernet Converged Network       5.05  1572 00:004 Up to date

    Adapter X710-4

02) Intel(R) I350 Gigabit Network Connection  1.99  1521 00:129 Update not

                                                                available

03) Intel(R) Ethernet Converged Network       5.05  1572 00:133 Up to date

    Adapter X710-4

On the other box, it will not let me upgrade:

driver: i40e

version: 2.0.23

firmware-version: 4.10 0x800011c5 0.0.0

bus-info: 0000:01:00.1

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

WARNING: To avoid damage to your device, do not stop the update or reboot or power off the system during this update.

Inventory in progress. Please wait [|.........]

Num Description                               Ver. DevId S:B    Status

=== ======================================== ===== ===== ====== ===============

01) Intel(R) Ethernet Converged Network       4.10  1572 00:001 Update not

    Adapter X710-4                                              available

02) Intel(R) I350 Gigabit Network Connection  1.99  1521 00:129 Update not

                                                                available

03) Intel(R) Ethernet Converged Network       4.10  1572 00:130 Update not

    Adapter X710-4                                              available

Does anyone know what's wrong?

I can't replicate the issue but every few weeks my NIC disables itself and I have to restart my computer to get it to work again since disabling / re enabling in Device Manager stalls.

From searching online, "Receive Side Scaling" is the reason.  Why would this be the case?   Would this be due to the manufacturer of the motherboard or Intel?  I tried Asus' drivers and also tried the latest Intel drivers - doesn't matter.

I purchased a motherboard that came with an Intel 82599 10-Gigabit network adapter (rev 01). I knew nothing about it when I bought the board; I simply want a network connection, regardless of the speed. I have it connected to a normal consumer-grade router (almost certainly not 10 gbps, although its speed isn't stated) with an ordinary ethernet cable. The setup connects just fine with my laptop, but never gets past "Link not ready" on the new system.  I installed the ixgbe driver, but it doesn't help any. I was reading the (amazingly long...) Readme that comes with the driver and I don't understand the half of it. It sounds like you may have to do something special to connect to a non-10 Gbps link with it?  I don't care about connection speed, I just want a connection.

Sorry for such a newbie question!

I have an Asus Z170 Pro Gaming motherboard with the I219-V LAN port but even on a fresh Windows 7 or Windows 10 installation, the port always shows up as having the (2) prefix even though its the only LAN port available and its the first time drivers have been installed for it (for that OS installation after formatting the HDD). The driver version I'm currently using is 12.15.25.6 from earlier this year.

I'm pretty sure that at some stage I've seen it as simply Intel(R) Ethernet Connection I219-V and I'd like to get back to that but how? FWIW the hardware is working fine, I'm just fussy about my system configuration and would like this to be as originally intended.

Hi Intel,

I'd like to get the ULP tool.

Best Regards,

naok

Hi ,

I was  trying to set up Intel XL710 in 2x40 mode using the QCU but I am getting the error ""QSFP+ Configuration modification is not supported by this adapter."

Although If I try to check the current configuration it shows the mode as N/A.

All the steps that I followed:

[root@ndr730l:/tmp/EFIx64] ./qcu64e /devices

Intel(R) QSFP+ Configuration Utility

QCU version: v2.27.10.01

Copyright(C) 2016 by Intel Corporation.

Software released under Intel Proprietary License.

NIC Seg:Bus Ven-Dev Mode    Adapter Name

=== ======= ========= ======= ==================================================

1) 000:005 8086-1583 N/A Intel(R) Ethernet Converged Network Adapter XL710-

[root@ndr730l:/tmp/EFIx64] ./qcu64e /info /nic=1

Intel(R) QSFP+ Configuration Utility

QCU version: v2.27.10.01

Copyright(C) 2016 by Intel Corporation.

Software released under Intel Proprietary License.

QSFP+ Configuration modification is not supported by this adapter.

MAC Address: 3CFDFE16FE80

Serial Number: XL710QDA2BLK

Firmware details:

ethtool -i vmnic4

driver: i40e

version: 1.4.28

firmware-version: 5.04 0x800024d8 17.5.10

bus-info: 0000:05:00.0

Hi there,

I have 2x the same setup of one X540-T1 network card in a Logic Supply MK100B-50 (ASRock IMB-181-D Motherboard) and in both computers, after a certain amount of usage, the X540-T1 card stops working. When I go in the Windows Device Manager it says "Windows has stopped this device because it has reported problems. (code 43)"

I can disable and re-enable the device to make it work but only temporarly. The problem comes back.

I've also installed the latest intel driver. It says it is version 4.0.215.0 which was installed with the file: IntelNetworkDrivers-PROWinx64.exe.

Should this work?

Any ideas of how to fix this?

Thank you.

hi, i would like to report that the new intel nic drivers version 19.3 that just released recently has huge 6000+ dpc latency spike once in a few secs.

my specs

Intel(R) 82579LM Gigabit Network Connection

windows 7 SP1 32bit + lastest windows update

i downgrade to intel nic drivers previous version 19.1 and the problem is just gone.

HI

I want to add a floating veb in X710 network adapter and link two vfs to this veb .Please give me a method to do this.

Driver version: 2.0.23

Thanks

Hi there,

This is my first time posting on this forum. So here goes...

I noticed from using the "Reliability History" I noticed many crashes on the "WMI Provider Host". Looking at the details information it shows this:

Problem Event Name:    BEX64

Application Name:    wmiprvse.exe

Application Version:    6.2.9200.16398

Application Timestamp:    5033992e

Fault Module Name:    CoreAgnt.dll_unloaded

Fault Module Version:    0.0.0.0

Fault Module Timestamp:    58ecf841

Exception Offset:    000007fee8307e88

Exception Code:    c0000005

Exception Data:    0000000000000008

OS Version:    6.1.7601.2.1.0.256.48

Locale ID:    1033

Additional Information 1:    2264

Additional Information 2:    2264db07e74365624c50317d7b856ae9

Additional Information 3:    3ef2

Additional Information 4:    3ef25dd6ab33f02f72717e629f8b08ab

All the crashes involved WMIprvse.exe and the CoreAgnt.dll.  I noticed that the CoreAgnt.dll is part of the "Intel ProSet for the Device Manager". Ever since I've updated my one year old Ethernet driver, the crashes began.

The crashes only happen on startup or whenever you reboot the system. When the PC starts, there is no message pop-up indicating an error. Also when looking at the Network Adapter properties under Device Manager, it functions well with no issues while browsing the various settings.

I'm curious anyone else notice these crashes under Windows?

Hopefully Intel's software engineers would look into this. It never happened before from their previous drivers.

I have all the latest Windows 7 updates. I've also checked for virus using ESET NOD32 and found nothing.

Driver that's causing this issue is called:

Intel® Network Adapter Driver for Windows 7* version (22.4.0.1)

Here are my system specs:

Mobo: Asus Rampage 3 Extreme

CPU: Intel Core i7 930 @ 2.80Ghz (non-overclocked)

Memory: 12GB RAM

Video Card: MSI GeForce GTX 970 Gaming 4G

Sound Card: Sound Blaster Z

Ethernet: Intel 82567V-2 Gigabit Network (built-in from motherboard)

OS: Windows 7 64-bit SP1 Professional

FTech

Hi Everyone, Im trying to track down an issue with my LAN port,,My motherboard uses a Intel i219V controller and this is a new htpc mini itx build.

So far Ive looked over a few things such as downloading the latest drivers for the chipset and updating the bios on the asus board,,from the very first post

I have been skeptical of a hardware issue due to a lack of any port activity via the normal lights one expects to see from the ethernet port, in my limited experience

I usually see a light in or near the port no matter if it is active or not, this boards port has been silent of any lights so far,,however I thought i might run this by the

community here just in case someone else might have encountered a lan issue with this controller or a problem with Asus ROG products in respect to the network

controller, i am open to suggestions and have a fair amount experience with PC hardware and sometimes do repairs for friends and family.

any troubleshooting suggestions ? I hope maybe I would be so lucky as to have missed an option in the bios setup, but I havent looked into that yet,

Wireless on the asus board appears to work well and uses a qualcomm Atheros Dual band adapter and antenna. So far it performs well in any part of my home

but I prefer old school wired networking if at all possible,

This was motherboard number 2 as the first board came with some bent pins and had signs of being an open box,,this board however came packaged sealed and everything

checked out ok, first post went well after breadboarding it just to confirm it wasnt DOA,,anyone who has built into a small form factor case knows how much trouble this can save you.

So is the i219v have any current issues that might cause a ethernet port to appear dead ?

Hello All,

We have been trying to make Unicast promiscuous mode work with RHEL7.3 with latest native ixgbe driver (ixgbe-5.1.3), but it seems that unicast promiscuous mode is not enabled for 82599 series nic cards in the native driver.

I can see an explicit check in ixgbe_sriov.c code, where before enabling promiscuous mode, it checks if NIC card is equal(or lower) than 82599EB, it returns.

Adding snippet below:

        case IXGBEVF_XCAST_MODE_PROMISC:

                if (hw->mac.type <= ixgbe_mac_82599EB)

                        return -EOPNOTSUPP;

                fctrl = IXGBE_READ_REG(hw, IXGBE_FCTRL);

                if (!(fctrl & IXGBE_FCTRL_UPE)) {

                        /* VF promisc requires PF in promisc */

                        e_warn(drv,

                               "Enabling VF promisc requires PF in promisc\n");

                        return -EPERM;

                }

                disable = 0;

                enable = IXGBE_VMOLR_BAM | IXGBE_VMOLR_ROMPE |

                         IXGBE_VMOLR_MPE | IXGBE_VMOLR_UPE | IXGBE_VMOLR_VPE;

                break;

But, when I see the corresponding code in DPDK16.11 version, I can see the support has been added for 82599 NICs family. The feature seems to have implemented using IXGBE_VMOLR_ROPE  flag.

Relevant snippet from DPDK code:

uint32_t

ixgbe_convert_vm_rx_mask_to_val(uint16_t rx_mask, uint32_t orig_val)

{

        uint32_t new_val = orig_val;

        if (rx_mask & ETH_VMDQ_ACCEPT_UNTAG)

                new_val |= IXGBE_VMOLR_AUPE;

        if (rx_mask & ETH_VMDQ_ACCEPT_HASH_MC)

                new_val |= IXGBE_VMOLR_ROMPE;

        if (rx_mask & ETH_VMDQ_ACCEPT_HASH_UC)

                new_val |= IXGBE_VMOLR_ROPE;

        if (rx_mask & ETH_VMDQ_ACCEPT_BROADCAST)

                new_val |= IXGBE_VMOLR_BAM;

        if (rx_mask & ETH_VMDQ_ACCEPT_MULTICAST)

                new_val |= IXGBE_VMOLR_MPE;

        return new_val;

}

So, can you please let us know, why such difference between supported NIC ? and can we also have similar functionality ported to the native ixgbe driver?

Other setup details

Kernel version

# uname -r

3.10.0-514.el7.x86_64

LSPCI output

# lspci -nn | grep Ether | grep 82599

81:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

81:00.1 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

81:10.0 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)

# ethtool -i eth2

driver: ixgbe

version: 5.1.3

firmware-version: 0x61bd0001

expansion-rom-version:

bus-info: 0000:81:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

Regards

Pratik

Hi All,

I am trying to launch on VMs on RHEL7.3. I am using SRIOV for VM networking and default ixgbe version which comes along with RHEL7.3 is version: 4.4.0-k-rh7.3.

Though I am successfully able to send icmp traffic between VM and remote side physical machine.

But, I am trying to configure my VM as plain L2 device, with capability to accept packets with Unknown Unicast address. For this, I am configuring the VF in trust mode, but I am still see packets with mac addresses other than VF mac gets dropped.

So, can any one please confirm if 82599ES nic card has any hardware limitation due to which it won't support unicast promiscuous mode ?  or has anyone made it work with 82599ES nic card?

Thanks in advance.

Thanks

Pratik

I have configured host with two PF and 16 x2 VF in debian system. It worked well if I use the PF/VF as standalone NIC, but not functional with OVS bridge.

The testing scenario as below:

eth0 (PF): 10.250.11.103/24

eth11 (VF 9): 10.250.11.113/24

   Bridge "vmbr1"

        Port "eth10"

            Interface "eth10" (VF 8)

        Port "vmbr1"

            Interface "vmbr1"

                type: internal

        Port "in1"

            Interface "in1"

                type: internal

    ovs_version: "2.6.0"

in1: 10.250.11.34/24

I try the following icmp test:

ping 10.250.11.254 (reply good)

ping 10.250.11.254 -I eth11 (reply good)

ping 10.250.11.254 -I in1 (NO response)

ip link show my VF as:

-------------------------------

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000

    link/ether 0c:c4:7a:df:36:c6 brd ff:ff:ff:ff:ff:ff

    vf 0 MAC 6e:74:9e:65:58:eb, spoof checking on, link-state auto

    vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

    vf 2 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

    vf 3 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

    vf 4 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

    vf 5 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

    vf 6 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

    vf 7 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

    vf 8 MAC da:c7:06:0b:5b:1f, spoof checking on, link-state auto

    vf 9 MAC ea:97:12:4e:b4:6b, spoof checking on, link-state auto

    vf 10 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

    vf 11 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

    vf 12 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

    vf 13 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

    vf 14 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

    vf 15 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

arp table shown as:

-------------------------------

Address                  HWtype  HWaddress           Flags Mask            Iface

10.250.11.254            ether   6c:3b:6b:e9:7c:e1   C                     eth11

10.250.11.254            ether   6c:3b:6b:e9:7c:e1   C                     eth0

10.250.11.254            ether   6c:3b:6b:e9:7c:e1   C                     in1

But arp is not stable, it disappear very quickly:

------------------------------------------------------------

Address                  HWtype  HWaddress           Flags Mask            Iface

10.250.11.254                   (incomplete)                              in1

10.250.11.254            ether   6c:3b:6b:e9:7c:e1   C                     eth0

10.250.11.254            ether   6c:3b:6b:e9:7c:e1   C                     eth11

The strange thing is:

ping via in1 will not fill up the arp table for in1 Iface (always show incomplete), but ping via other two iface seems fill the mac address into in1 some time.

I have tcpdump to in1 and found it send out ARP request broadcast, but did not get any ARP reply from host 254.

ovs-appctl fdb/show vmbr1:

-----------------------------------------

port  VLAN  MAC                Age

    2     0  72:fc:b4:3a:e6:0f   78

    1     0  6c:3b:6b:e9:7c:e1   38

    1     0  6c:3b:6b:f5:96:e6    3

    1     0  88:43:e1:dd:9c:80    1

This looks persist and will not change whatever I ping via any Iface.

I have also try to change VF port, but seems none of them work with OVS bridge.

But the bridge worked if assigned the port to eth0 or eth1 PF.

uname -a:

Linux pve3 4.4.62-1-pve #1 SMP PVE 4.4.62-88 (Thu, 18 May 2017 09:18:43 +0200) x86_64 GNU/Linux

/etc/network/interfaces:

----------------------------------

auto eth0

iface eth0 inet static

        address  10.250.11.103

        netmask  255.255.255.0

        gateway  10.250.11.254

auto eth11

iface eth11 inet static

        address  10.250.11.113

        netmask  255.255.255.0

allow-vmbr1 eth10

iface eth10 inet manual

        ovs_type OVSPort

        ovs_bridge vmbr1

auto vmbr1

iface vmbr1 inet manual

        ovs_type OVSBridge

        ovs_ports eth10 in1

allow-vmbr1 in1

iface in1 inet static

        address  10.250.11.34

        netmask  255.255.255.0

        ovs_type OVSIntPort

        ovs_bridge vmbr1

Here is ethtool info for eth10:

-------------------------------

# ethtool -i eth10

driver: ixgbevf

version: 2.12.1-k

firmware-version:

bus-info: 0000:05:12.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: no

supports-register-dump: yes

supports-priv-flags: no

#ethtool -k eth10

Features for eth10:

rx-checksumming: on

tx-checksumming: on

        tx-checksum-ipv4: off [fixed]

        tx-checksum-ip-generic: on

        tx-checksum-ipv6: off [fixed]

        tx-checksum-fcoe-crc: off [fixed]

        tx-checksum-sctp: on

scatter-gather: on

        tx-scatter-gather: on

        tx-scatter-gather-fraglist: off [fixed]

tcp-segmentation-offload: on

        tx-tcp-segmentation: on

        tx-tcp-ecn-segmentation: off [fixed]

        tx-tcp6-segmentation: on

udp-fragmentation-offload: off [fixed]

generic-segmentation-offload: on

generic-receive-offload: on

large-receive-offload: off [fixed]

rx-vlan-offload: on [fixed]

tx-vlan-offload: on [fixed]

ntuple-filters: off [fixed]

receive-hashing: off [fixed]

highdma: on [fixed]

rx-vlan-filter: on [fixed]

vlan-challenged: off [fixed]

tx-lockless: off [fixed]

netns-local: off [fixed]

tx-gso-robust: off [fixed]

tx-fcoe-segmentation: off [fixed]

tx-gre-segmentation: off [fixed]

tx-ipip-segmentation: off [fixed]

tx-sit-segmentation: off [fixed]

tx-udp_tnl-segmentation: off [fixed]

fcoe-mtu: off [fixed]

tx-nocache-copy: off

loopback: off [fixed]

rx-fcs: off [fixed]

rx-all: off [fixed]

tx-vlan-stag-hw-insert: off [fixed]

rx-vlan-stag-hw-parse: off [fixed]

rx-vlan-stag-filter: off [fixed]

l2-fwd-offload: off [fixed]

busy-poll: on [fixed]

hw-tc-offload: off [fixed]

-------------------------------

Is there any advice?

Hi Intel,

I would like to read-out the module eeprom of QSFP transceiver connected to a XL710-QDA1 NIC.

The naive approach failed:  ethtool -m eth0. It reports: "Cannot get module EEPROM information: Operation not supported"

Is this feature supported by the NIC and the Intel driver i40e?

I am using the following driver and firmware:

driver version: 2.0.23

firmware-version: 5.05 0x800028a2 1.1568.0

Thanks and kind regards

Thomas Dey

I am trying to filter network packets based on vlan tag ids.  Using wireshark I can capture/inspect packets with 2 different VLAN IDs on my network.  I was hoping to suppress packets associated a particular VLAN ID.  So, using the ethtool I added a hardware filter as follows:

sudo ethtool -U eth11 flow-type udp4 vlan 0x65 vlan-ask 0xE000 action -1 and

sudo ethtool -U eth11 flow-type udp4 vlan 0x67 vlan-ask 0xE000 action -1

Both commands are accepted (I observe 2  message indicating that rule 2001 and 2002 has been added, respectively)

After execution of the above commands,  no packets associated with VLAN 0x65 or 0x67 are received (good - what I expected).  As soon as I clear

one of the hardware filters via ethtool (sudo ethtool eth11 delete 2001) I receive packets associated with both VLAN Tags 0x65 and 0x66).

I was wondering if intel driver i40e truely supports hardware filtering? 

Thanks

I can't get connected to the internet. I get the message not connected. Connection on other computers working fine. I think it started when I tried to updat the driver. Intel says adapter not supported for windows 10.  I can't find the generic driver. Also, get a error 651. Can anybody help?

Thanks

Dick Prosser

deprosser@comcast.net

Hi,

I am trying to configure 802.1ad on ixgbe vfs with a goal of moving resultant q-in-q interface into a container i.e. have the vf in default namespace and have all the vf's vlan interfaces being moved to different namespaces. Theoretically in this configuration, packets would be double-tagged coming into pf, be directed to correct vf (and outer tag stripped) and then delivered to linux with single-tag.

I tried this:

# echo 32 > /sys/class/net/eth1/device/sriov_numvfs

# ip link set dev eth1 up

# ip link set dev eth1 vf 1 vlan 2 proto 802.1ad

RTNETLINK answers: Protocol not supported

Is there a way I can do this ?

TIA,

Don.

Howdy,

I've been wondering since I installed Windows 10 how to install the drivers (right now, 22.4.0.1; here) for Intel Gigabit CT Desktop adapter? I've tried several other versions, but all just say: "Cannot install drivers. No Intel(R) Adapters are present in this computer." I think this would install just fine with Windows 7, but not in Windows 10. Anyway, screenshot attached below.

Hi All,

I am using RHEL7.3 with Intel-82599ES nic cards to launch VMs with SRIOV enabled nic cards. I am using configuring only one VF per PF. I am configuring this VF with vlan, trust mode on and disabling spoof chk.

But, when I am sending vlan tagged packets from Guest VM, I can see the "spoofed packet detected" message in dmesg for this PF card.

We have also disabled the rx/tx vlan offload using ethtool command.

Here are setup details:

Kernel version

# uname -r

3.10.0-514.el7.x86_64

PF/VF configuration:

# ip link show eth2

4: eth2: <BROADCAST,MULTICAST,ALLMULTI,PROMISC,UP,LOWER_UP> mtu 9192 qdisc mq state UP mode DEFAULT qlen 1000

    link/ether 90:e2:ba:a5:98:7c brd ff:ff:ff:ff:ff:ff

    vf 0 MAC fa:16:3e:73:12:6c, vlan 1500, spoof checking off, link-state auto, trust on

IXGBE version

# ethtool -i eth2

driver: ixgbe

version: 4.4.0-k-rh7.3

firmware-version: 0x61bd0001

expansion-rom-version:

bus-info: 0000:81:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: no

Messages from dmesg

[441100.018278] ixgbe 0000:81:00.0 eth2: 3 Spoofed packets detected

[441102.022383] ixgbe 0000:81:00.0 eth2: 2 Spoofed packets detected

[441104.026460] ixgbe 0000:81:00.0 eth2: 3 Spoofed packets detected

[441106.030516] ixgbe 0000:81:00.0 eth2: 2 Spoofed packets detected

LSPCI output

# lspci -nn | grep Ether | grep 82599

81:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

81:00.1 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

81:10.0 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)

Ethtool -k output

# ethtool -k eth2 | grep vlan

rx-vlan-offload: off

tx-vlan-offload: off

rx-vlan-filter: on

vlan-challenged: off [fixed]

tx-vlan-stag-hw-insert: off [fixed]

rx-vlan-stag-hw-parse: off [fixed]

rx-vlan-stag-filter: off [fixed]

Please let me know, if you any need any other information.

Regards

Pratik