netdev - qeth_l2 duplicated frames in promiscuous mode

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

Date:	Tue, 26 Feb 2013 16:08:37 -0500
From:	Benjamin Poirier <bpoirier@...e.de>
To:	Ursula Braun <ursula.braun@...ibm.com>,
	Frank Blaschka <blaschka@...ux.vnet.ibm.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>
Cc:	Mark Post <mpost@...e.com>, linux390@...ibm.com,
	linux-s390@...r.kernel.org, netdev@...r.kernel.org
Subject: qeth_l2 duplicated frames in promiscuous mode

Hello,

While working with the qeth/qeth_l2 drivers I've noticed that once the
nic enters promiscuous mode, every received frame is duplicated. This
appears to happen at the (virtual) hardware level since the "RX Packets"
counter printed by `#cp q nic [...] det` shows this duplicated count. It
also happens when setting promiscuous mode using `#cp set nic [...]
pro`.

It can be witnessed in tcpdump output or simply by pinging the machine
from another host. As soon as promiscuous mode is enabled using the cp
command above, the machine receives the echo request in duplicate and
answers them accordingly:
64 bytes from 10.121.155.133: icmp_seq=61 ttl=64 time=0.314 ms
64 bytes from 10.121.155.133: icmp_seq=62 ttl=64 time=0.308 ms
# enable promiscuous mode on 10.121.155.133 now
64 bytes from 10.121.155.133: icmp_seq=63 ttl=64 time=0.301 ms
64 bytes from 10.121.155.133: icmp_seq=63 ttl=64 time=0.326 ms (DUP!)
64 bytes from 10.121.155.133: icmp_seq=64 ttl=64 time=0.309 ms
64 bytes from 10.121.155.133: icmp_seq=64 ttl=64 time=0.330 ms (DUP!)

This duplication happens for multicast and unicast frames, whether those
are directed to an address in the uc filter list or not.

Tested on v3.8.

Is this a known issue?

Here is the nic info, let me know if you need anything else, I'm not
familiar with s390.

CP Q NIC 0800 DET
Adapter 0800.P00 Type: QDIO      Name: UNASSIGNED  Devices: 3
  MAC: 02-00-00-00-00-07         VSWITCH: SYSTEM VSWNL2
      RX Packets: 3005625    Discarded: 1318       Errors: 0
      TX Packets: 287690     Discarded: 0          Errors: 0
      RX Bytes: 3777624734           TX Bytes: 32040428
  Connection Name: HALLOLE   State: Session Established
      Device: 0800  Unit: 000   Role: CTL-READ
      Device: 0801  Unit: 001   Role: CTL-WRITE
      Device: 0802  Unit: 002   Role: DATA       vPort: 0264  Index: 0264
      VLAN: 0556
      Options: Ethernet Broadcast Promiscuous
        Unicast MAC Addresses:
          02-00-00-00-00-07
        Multicast MAC Addresses:
          01-00-5E-00-00-01
          33-33-00-00-00-01
          33-33-00-00-02-02
          33-33-FF-00-00-07

Thank you,
-Benjamin
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html