netdev - Re: PROBLEM: QinQ not working with qlcnic drivers

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] [day] [month] [year] [list]

Date:   Fri, 4 Sep 2020 17:05:31 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     MyNet SysAdmin <sysadmin@...et.it>
Cc:     netdev@...r.kernel.org, GR-Linux-NIC-Dev@...vell.com,
        Shahed Shaikh <shshaikh@...vell.com>,
        Manish Chopra <manishc@...vell.com>
Subject: Re: PROBLEM: QinQ not working with qlcnic drivers

CC: qlcnic maintainers

On Fri, 4 Sep 2020 11:25:27 +0200 MyNet SysAdmin wrote:
> *[1.] One line summary of the problem:*
> 
> QinQ not working with qlcnicdrivers
> 
> *[2.] Full description of the problem/report:*
> 
> QinQ networking operations don’t happenproperly: a QinQ message can be 
> received by the NIC and a correct outputgetsgenerated by the server but 
> the QinQ encapsulation for the responsedoesnot take place.
> 
> tcpdump output statesthat the packet has both first and second tagbut 
> further analysis on the traffic using a switch and a sniffer (monitoring 
> the port with the SPANfunction on a cisco switch)makes it clear that the 
> packet travels tagged only with the second tag (the first is not 
> present)andnot double tagged.
> 
> 
> *[3.]* *Keywords (i.e., modules, networking, kernel):*
> 
> networking, QinQ, qlcnic, vlan, nic, driver, HP, 802.1q
> 
> *[4.] Kernel information*
> 
> 5.8.5 generic
> 
> *[4.1.]* *Kernel version (from /proc/version):*
> 
> Linux version 5.8.5-050805-generic (kernel@...gerine)
> (gcc (Ubuntu 10.2.0-5ubuntu2) 10.2.0, GNU ld (GNU Binutils for Ubuntu) 
> 2.35) #202008270831 SMP Thu Aug 27 08:33:39 UTC 2020
> 
> *[4.2.] Kernel .config file: _see attached_ “config.txt”*
> 
> *[5.] Most recent kernel version which did not have the bug: *
> 
> not known
> 
> *[6.] Output of Oops.. message (if applicable) with symbolic information 
> resolved (see Documentation/admin-guide/bug-hunting.rst)*
> 
> not applicable
> 
> *[7.] A small shell script or example program which triggers the problem 
> (if possible)*
> 
> ip link add link enp11s0f1 name v.4 type vlan id 4000
> ip link add link v.4 name v.4.3 type vlan id 3999
> ip a a 172.20.20.5/24 dev v.4.3
> ping 172.20.20.1
> 
> *[8.] Environment*
> HP proLiant rackmount server model DL360e Gen8;
> HP NC523SFP / QLE3242-CU(Qlogic clom8214controller)NIC;
> CISCO switch with a monitor port set on the server’s NIC;
> sniffer on the monitor port;
> 
> *[8.1.] Software (add the output of the ver_linux script here): see 
> attached “ver_linux.txt”*
> 
> *[8.2.] Processor information (from /proc/cpuinfo): _see attached_ 
> “proc-cpuinfo.txt”*
> 
> *[8.3.] Module information (from /proc/modules): see attached 
> “proc-modules.txt”*
> 
> *[8.4.] Loaded driver and hardware information (/proc/ioports, 
> /proc/iomem): see attached “iomem.txt” and “ioports.txt”*
> 
> *[8.5.] PCI information ('lspci -vvv' as root): see attached “lspci.txt”*
> 
> *[8.6.] SCSI information (from /proc/scsi/scsi): see attached 
> “proc-scsi-scsi.txt”*
> 
> *[8.7.] Other information that might be relevant to the problem*
>         *(please look in /proc and include all information that you*
>         *think to be relevant):*
> 
> this is the output of ethtool -i for the interface
> 
> driver: qlcnic
> version: 5.3.66
> firmware-version: 4.14.26
> expansion-rom-version:
> bus-info: 0000:03:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: no
> 
> The server is connected to a switch through the NC523SFP,the other end 
> of the communication is another server, proven to work as intended with 
> QinQ by a test made with a third device and the same switch.
> The same configuration used for the NC523SFP is proven to work with the 
> other end of the communication using the integrated ethernet NIC.
> Along with the other information there’s a file called monitor.pcap that 
> is the capture taken from the switch, of the problemand also a file 
> called host.pcap that is the output of tcpdump done on the host.
> 
> *[**9**.] Other notes, patches, fixes, workarounds:*
> 
> the same setup has been tested with kernels:
> 
> 5.0.0-38
> 5.4.0-050400
> 5.4.0-45
> 5.4.7-050407
> 5.8.5-050805
> 
> none of them worked. Best regards, Luca Garusi.
>