[TW#27190] Multicast Example Does not work on Ethernet

[benpeoples]

Environment

• Development Kit: [none]
• Kit version (for WroverKit/PicoKit/DevKitC): []
• Module or chip used: [ESP32-WROOM-32]
• IDF version (run git describe --tags to find it):
  // v3.2-dev-1429-g7efbe8178
• Build System: Unknown
• Compiler version (run xtensa-esp32-elf-gcc --version to find it):
  // xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 5.2.0
• Operating System: [macOS]
• Power Supply: [external 3.3V]

Problem Description

• Running the example/udp_multicast works via WiFi but does not work via Ethernet.
• This is the code I am running: https://pastebin.com/S2J8BehK
• Unicast data to the port is received by the system
• I can wireshark the IGMP packets being emitted by the ESP32 over ethernet, and the network switch appears to recognize this, as I can see the activity lights on the Ethernet port receiving the multicast traffic.
• Some earlier diagnostics indicated that the multicast packets were not even making it to the config.tcpip_input function, so they may be being filtered by the emac? My digging stopped there.

Expected Behavior

• Subscribing to a multicast address should route multicast traffic to the socket.

Actual Behavior

• Subscribing to a multicast address does not route multicast traffic to the socket.

Steps to repropduce

Code to reproduce this issue

https://pastebin.com/S2J8BehK

Debug Logs

Other items if possible

[suda-morris]

@benpeoples Yes, by default the mac will filter the multicast address if they could not match the address by Perfect Filter. Since we haven't configured any supported multicast address, so the emac will filter all received multicast frames.
This bug will be fixed soon. Thanks for your suggestion and deep analysis for this issue.

[benpeoples]

Thank you!

To be clear, this is an issue with only EMACADDR0 being selected for Perfect Filter, and I could adjust registers to workaround the issue directly? That is, it's a driver issue not a silicon issue?

[suda-morris]

@benpeoples Yes, it's a driver issue.

[vtamas00]

It can be a working workaround if I set the Frame Filter Register PAM bit (Pass All Multicast) to 1?
What is the location of the EMAC Write Reg function/macro?

[benpeoples]

That should work in theory (that's the first thing I'm going to try), and it should generally work if you have well-behaved switches on the network.

I would look at emac_main.c for examples of how to modify the EMAC registers.

[vtamas00]

I insterted this code into my main.c:

    uint32_t EMACFF = REG_READ( EMAC_GMACFF_REG );
    REG_WRITE( EMAC_GMACFF_REG , EMAC_PAM | EMACFF );

and the UDP multicast receiving starts to operate!
But I noticed a new problem:
I have a FreeRTOS task for the ipv4 udp multicast rx and an other realize a simple tcp server (both based on the examples). If both task are run the TCP task cant accept connections: Unable to accept connection: errno 113. If only the tcp server run, it works perfect.
Could be any conflict theoretically between TCP accept() and a configured UDP multicast task? If yes, what could cause this?

[vtamas00]

I found the problem. My UDP task uses select(). If I eliminate select() the tcp server accept() works. So the select() is not a thread safe function?

[suda-morris]

@vtamas00 We have fixed the multicast issue by add REG_SET_BIT(EMAC_GMACFF_REG, EMAC_PAM); in the function emac_mac_init (located at emac_dev.c file). The patch will be available soon.
And the select function should be thread safe as far as I know. For that problem, I suggest you to raise another issue with more detailed information about it.