TSE MAC - disabled promiscuous mode does not filter packets
From my customer:
Our QSys configuration for the Cyclone 10 LP includes Nios II, on-chip RAM, FIFOs, mSGDMA, TSE MAC to an external PHY (Marvell 88E1510).
Is there something else needed to disable promiscuous mode? Or is the TSE MAC just not behaving as advertised?
The TSE user guide states that promiscuous mode is enabled when command_config.PROMIS_EN (bit 4) is 1 and disabled when 0.
I have a controller board connected to a secondary NIC on my Windows 10 PC. Not surprisingly, packets are being sent by the secondary NIC to the controller. Typically I see four (4) ARP packets followed by 14 IPv4 packets when I first connect the Ethernet cable. Activity then slows down afterwards. The same thing repeats when I start running my Nios II application. I expect ARP packets to get through since they’re broadcast, but not so for the IPv4 packets.
----- packet capture by Wireshark v3.0.5 -----
Frame 28: 216 bytes on wire (1728 bits), 216 bytes captured (1728 bits) on interface 0
Ethernet II, Src: a0:36:9f:6e:b9:ed, Dst: 01:00:5e:7f:ff:fa
Destination: 01:00:5e:7f:ff:fa
Source: a0:36:9f:6e:b9:ed
Type: IPv4 (0x0800)
Frame check sequence: 0x0d0a0d0a [unverified]
[FCS Status: Unverified]
Data (198 bytes)
-----
In this case, a0:36:9f:6e:b9:ed is the MAC address for the secondary NIC. The MAC address for the controller is 00:25:8A:00:00:07, but that has yet to even be made known to the outside world. I’m not at all sure where 01:00:5e:7f:ff:fa came from.
---- corresponding snippet from Nios II console window -----
Debug Info: 220 bytes in packet
Debug Info: received EtherType value 0x0800
Debug Info: received IPv4 packet
Debug Info: read TSE MAC command config as 0x00000263 <-- bit 4 is 0
Critical Warning: TSE MAC is not in promiscuous mode
-----
mac_0 = 0x008A2500
mac_1 = 0x0700
smac_0_0 = 0x573E000D
smac_0_1 = 0x5449
smac_1_0 = 0x573E000D
smac_1_1 = 0x5449
smac_0_0 = 0x008A2500
smac_2_1 = 0x0700
smac_3_0 = 0x008A2500
smac_3_1 = 0x0700
The incoming MAC (destination) address of 01:00:5e:7f:ff:fa doesn’t match any of the TSE registers for MAC addresses.
command_config.PROMIS_EN (bit 4) is 0; consequently, I shouldn’t have been given this packet.