Skip to content

Conversation

@me-no-dev
Copy link
Member

This pull request updates the method used to retrieve the MAC address for Ethernet interfaces in the ETHClass::beginSPI function. The change improves hardware compatibility and clarifies error logging.

Hardware compatibility and error handling improvements:

  • In ETH.cpp, replaced the call to esp_efuse_mac_get_default with esp_read_mac(base_mac_addr, ESP_MAC_ETH) to use the correct API for obtaining the Ethernet MAC address, and updated the log message to clarify the source of failure.

@github-actions
Copy link
Contributor

Messages
📖 🎉 Good Job! All checks are passing!

👋 Hello me-no-dev, we appreciate your contribution to this project!


📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more.

🖊️ Please also make sure you have read and signed the Contributor License Agreement for this project.

Click to see more instructions ...


This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...


We do welcome contributions in the form of bug reports, feature requests and pull requests.

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
4. If the change is approved and passes the tests it is merged into the default branch.

Generated by 🚫 dangerJS against 88877e5

@github-actions
Copy link
Contributor

Memory usage test (comparing PR against master branch)

The table below shows the summary of memory usage change (decrease - increase) in bytes and percentage for each target.

MemoryFLASH [bytes]FLASH [%]RAM [bytes]RAM [%]
TargetDECINCDECINCDECINCDECINC
ESP32C50⚠️ +12560.00⚠️ +0.210⚠️ +1120.00⚠️ +0.51
ESP32P4💚 -2⚠️ +10200.00⚠️ +0.170⚠️ +400.00⚠️ +0.15
ESP32S30⚠️ +9080.00⚠️ +0.160⚠️ +640.00⚠️ +0.25
ESP32S20⚠️ +9760.00⚠️ +0.190⚠️ +480.00⚠️ +0.23
ESP32C30⚠️ +11360.00⚠️ +0.200⚠️ +640.00⚠️ +0.36
ESP32C60⚠️ +12460.00⚠️ +0.230⚠️ +1120.00⚠️ +0.58
ESP32H20⚠️ +10960.00⚠️ +0.190⚠️ +880.00⚠️ +0.46
ESP320⚠️ +9760.00⚠️ +0.180⚠️ +320.00⚠️ +0.12
Click to expand the detailed deltas report [usage change in BYTES]
TargetESP32C5ESP32P4ESP32S3ESP32S2ESP32C3ESP32C6ESP32H2ESP32
ExampleFLASHRAMFLASHRAMFLASHRAMFLASHRAMFLASHRAMFLASHRAMFLASHRAMFLASHRAM
libraries/Ethernet/examples/ETH_W5500_Arduino_SPI⚠️ +1256⚠️ +112⚠️ +1020⚠️ +40⚠️ +876⚠️ +64⚠️ +976⚠️ +48⚠️ +1136⚠️ +64⚠️ +1246⚠️ +112⚠️ +1096⚠️ +88⚠️ +964⚠️ +32
libraries/Ethernet/examples/ETH_W5500_IDF_SPI⚠️ +1256⚠️ +112⚠️ +1020⚠️ +40⚠️ +908⚠️ +64⚠️ +944⚠️ +48⚠️ +1136⚠️ +64⚠️ +1246⚠️ +112⚠️ +1096⚠️ +88⚠️ +976⚠️ +32
libraries/Ethernet/examples/ETH_WIFI_BRIDGE⚠️ +20💚 -20⚠️ +40⚠️ +40⚠️ +20⚠️ +20--00
libraries/Ethernet/examples/ETH_TLK110--00----------00
libraries/Ethernet/examples/ETH_LAN8720--------------00

@me-no-dev me-no-dev added the Status: Review needed Issue or PR is awaiting review label Oct 27, 2025
@github-actions
Copy link
Contributor

github-actions bot commented Oct 27, 2025

Test Results

 76 files   76 suites   16m 50s ⏱️
 38 tests  38 ✅ 0 💤 0 ❌
241 runs  241 ✅ 0 💤 0 ❌

Results for commit 88877e5.

♻️ This comment has been updated with latest results.

@TD-er
Copy link
Contributor

TD-er commented Oct 28, 2025

Tried it and it is working fine.
On my ESP32-S3 board with W5500 SPI Ethernet it now is assigned
DA:54:75:CB:C3:ED, where it was DE:54:75:CB:C3:EC before. (The same as WIFI_SOFTAP, which is the "locally administred" of WIFI_STA)

Just for completeness, these are the MAC-addresses as stored in the EFUSE MAC of the ESP:

DC:54:75:CB:C3:EC      ESP_MAC_WIFI_STA,      /**< MAC for WiFi Station (6 bytes) */
DE:54:75:CB:C3:EC      ESP_MAC_WIFI_SOFTAP,   /**< MAC for WiFi Soft-AP (6 bytes) */
DC:54:75:CB:C3:ED      ESP_MAC_BT,            /**< MAC for Bluetooth (6 bytes) */
DE:54:75:CB:C3:ED      ESP_MAC_ETH,           /**< MAC for Ethernet (6 bytes) */
00:00:00:00:00:00      ESP_MAC_IEEE802154,    /**< if CONFIG_SOC_IEEE802154_SUPPORTED=y, MAC for IEEE802154 (8 bytes) */
DC:54:75:CB:C3:EC      ESP_MAC_BASE,          /**< Base MAC for that used for other MAC types (6 bytes) */
DC:54:75:CB:C3:EC      ESP_MAC_EFUSE_FACTORY, /**< MAC_FACTORY eFuse which was burned by Espressif in production (6 bytes) */
00:00:00:00:00:00      ESP_MAC_EFUSE_CUSTOM,  /**< MAC_CUSTOM eFuse which was can be burned by customer (6 bytes) */
00:00:00:00:00:00      ESP_MAC_EFUSE_EXT      /**< if CONFIG_SOC_IEEE802154_SUPPORTED=y, MAC_EXT eFuse which is used as an extender for IEEE802154 MAC (2 bytes) */

So it used DE:54:75:CB:C3:ED (ESP_MAC_ETH) and since bit 2 of the first octet was already set, it XOR'ed DE with 0x04 -> DA.

esp_err_t esp_derive_local_mac(uint8_t *local_mac, const uint8_t *universal_mac);

Derive local MAC address from universal MAC address.
This function copies a universal MAC address and then sets the "locally
administered" bit (bit 0x2) in the first octet, creating a locally administered MAC address.

If the universal MAC address argument is already a locally administered MAC address, then the first octet is XORed with 0x4 in order to create a different locally administered MAC address.

N.B. This also fixes (yet) unknown issues like why SPI Ethernet would probably not work on an ESP32-P4 as those have the first 3 MAC addresses set to 0. (probably same for ESP32-H2)

@arendst
Copy link
Contributor

arendst commented Oct 28, 2025

Pls also chk if the response from ETH.macAddress() is also the correct one.

While testing this fix I still see no difference between the WiFi MAC and the Ethernet Mac

14:01:56.205     "Hostname":"esp32p4",
14:01:56.205     "IPAddress":"192.168.2.226",
14:01:56.205     "Gateway":"192.168.2.254",
14:01:56.205     "Subnetmask":"255.255.255.0",
14:01:56.205     "DNSServer1":"192.168.2.24",
14:01:56.205     "DNSServer2":"192.168.2.25",
14:01:56.205     "Mac":"30:ED:A0:E1:F2:B8",
14:01:56.205     "IP6Global":"fd84:7996:2cbf:1349:b63a:45ff:fe83:3a34",
14:01:56.205     "IP6Local":"fe80::b63a:45ff:fe83:3a34%st3",
14:01:56.205     "Ethernet":{
14:01:56.205       "Hostname":"esp32p4-eth",
14:01:56.205       "IPAddress":"192.168.2.143",
14:01:56.205       "Gateway":"192.168.2.254",
14:01:56.205       "Subnetmask":"255.255.255.0",
14:01:56.205       "DNSServer1":"192.168.2.24",
14:01:56.205       "DNSServer2":"192.168.2.25",
14:01:56.205       "Mac":"30:ED:A0:E1:F2:B8",
14:01:56.205       "IP6Global":"fd84:7996:2cbf:1349:32ed:a0ff:fee1:f2b8",
14:01:56.205       "IP6Local":"fe80::32ed:a0ff:fee1:f2b8%en1"
14:01:56.205     }

@me-no-dev
Copy link
Member Author

@arendst you are running on P4 that does not have WiFi. Do not trust the MAC address that you get. The C6 that gives you WiFi has a different MAC address

@arendst
Copy link
Contributor

arendst commented Oct 28, 2025

You're right. Verified on C3 with ethernet. Thx.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Status: Review needed Issue or PR is awaiting review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants