Community
cancel
Showing results for 
Search instead for 
Did you mean: 
CBlow
Partner
369 Views

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.

 

 

0 Kudos
5 Replies
Deshi_Intel
Moderator
141 Views

Hi,

 

Your understanding is correct that the control bit for promiscuous mode is on command_config.PROMIS_EN (bit 4)

  • bit 4 = 1 (enable)
  • bit 4 = 0 (disable)

 

Attached is the screenshot of expected behaviour from TSE IP user guide doc for your reference. You can cross check it with your design.

 

One way to debug your issue would be to try out FPGA TSE MAC or PHY internal loopback feature to validate the expected function first. Once proven working, then you will know there could be some issue with external PHY or secondary NIC card.

 

Thanks.

 

Regards,

dlim

CBlow
Partner
141 Views

Thanks. We just found the IPv4 packets that keep getting passed along by the TSE MAC are of the multicast variety, not unicast as originally thought.

Deshi_Intel
Moderator
141 Views

Good to hear that !

 

So, that means the TSE IP is behaving as expected, right ?

 

Regards,

dlim

CBlow
Partner
141 Views

Deshi_Intel
Moderator
141 Views

Great !

Reply