- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good to hear that !
So, that means the TSE IP is behaving as expected, right ?
Regards,
dlim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Great !
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page