Why you don't want to use callback? Using `mac->receive` is not designed to be called from user code.

It seems your board is able to receive frames so the Rx path works. Now, check if Tx path works too. Connect your board to a PC and capture traffic using e.g. Wireshark to see if your board sends DHCP request. You can also try to run loopback test to see if there is no issue with RMII (https://githu...

It's pretty straight forward, just register your callback function to the Ethernet handler. See examples: https://github.com/espressif/esp-idf/blob/master/examples/network/simple_sniffer/main/cmd_sniffer.c#L300 https://github.com/espressif/esp-idf/blob/master/components/esp_eth/test_apps/main/esp_et...

Do you have your custom board or how did you connect IP101 to ESP32?

Hi, you are using the driver incorrectly. If your goal is to have your "custom" function to process received Ethernet frames, you need to register a call back function using `esp_eth_update_input_path`.

@DrMickeyLauer, here's the example of SPI Ethernet switch I found: https://www.microchip.com/en-us/product/LAN9352

Speaking of supported multiple Ethernet port ICs, we support KSZ8863. However, you've already figured it out by yourself as I've seen on Github

Great to hear you found the issue. One point regarding I would like to be able to disable the ability for the PC to connect to my LAN unless the packets are allowed by the ESP32 code. I'm not sure if "two port mode" is feasible for this use case. This mode is intended to provide your device two inde...

I tried it on my test board and "two_ports_mode" example works as expected. I got IP address at both ports. Do you use exact version of "two_ports_mode"? Or do you use some modified version of yours?

That's strange... The only thing which crossed my mind is the GPIO4 can be IO MUXed to EMAC_TX_ER function (see section 4.10 IO_MUX Pad List in TRM). Therefore make sure the GPIO4 is properly configured.