Fix KIT-VE Ethernet: PHY address should be 1, not 0

[Techman749]

Summary

The ESP32-ETHERNET-KIT-VE entry in ethernetBoards[] has eth_address set to 0, but the IP101GRI PHY on the Espressif ESP32-Ethernet-Kit V1.x actually responds at address 1. With address 0, ETH.begin() returns false immediately and silently — the precompiled arduino-esp32 v2.0.18 libraries have the IDF log level baked at info, so phy_802_3 power up timeout errors from the lower driver layers never reach the serial console. Users see "link LED on, no DHCP, no errors anywhere" and have generally concluded WLED simply doesn't work on this board.

This one-character change makes Ethernet work on the KIT-VE.

Verification

Tested on an ESP32-Ethernet-Kit V1.2 (A-board v1.2 + B-board v1.0) using a custom build of main at commit 186aafa with this fix applied.

Before: /json/info contained no eth block, device only reachable on WiFi. Serial debug log shows initE: Attempting ETH config: 7 → pin allocations → immediate initE: ETH.begin() failed with no further diagnostic output.

After: device obtains a DHCP lease on the Ethernet interface using a separate MAC (WiFi MAC + 3), is reachable on both interfaces simultaneously, and /json/info shows the Ethernet IP.

References

The correct PHY address for the IP101 on the KIT-VE is well documented:

• arduino-esp32#3554 — the PR that originally added IP101 support to arduino-esp32 explicitly notes: "The phy address for the IP101 on the ethernet kit is 1."
• Espressif's ESP-IDF Ethernet basic example for the KIT-VE configures CONFIG_EXAMPLE_ETH_PHY_ADDR=1
• esp32.com forum discussion — custom board referencing the KIT-VE pinout, same PHY Address: 1

Closes

This is the root cause of long-standing reports of "Ethernet doesn't work on KIT-VE" going back years:

• Ethernet set-up ESP32-ETHERNET-KIT-VE #2591 (board request / Ethernet not working, open since March 2022)
• WLED Discourse: "How to get Ethernet Working with ESP32-Ethernet Kit by Espressif"

Summary by CodeRabbit

• Bug Fixes
  • Corrected Ethernet connectivity configuration for ESP32-ETHERNET-KIT-VE board to ensure proper operation.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 8964e391-f613-4375-922f-5431f9819d27

📥 Commits

Reviewing files that changed from the base of the PR and between 91bcfc1 and 186aafa.

📒 Files selected for processing (1)

• wled00/network.cpp

---

Walkthrough

This PR contains a single configuration change to the Ethernet board lookup table in wled00/network.cpp. The eth_address field for the ESP32-ETHERNET-KIT-VE board entry is corrected from 0 to 1.

Changes

Ethernet Board Configuration

Layer / File(s)	Summary
Board address configuration correction wled00/network.cpp	The ethernetBoards[] table entry for ESP32-ETHERNET-KIT-VE updates eth_address from 0 to 1.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related PRs

• wled/WLED#5608: Both PRs touch wled00/network.cpp's Ethernet configuration table—this PR changes ethernetBoards[] for ESP32-ETHERNET-KIT-VE (eth_address 0→1), while the referenced PR adds compile-time sanity checks ensuring the table and default values are consistent with enum ranges.

Suggested reviewers

• DedeHai
• softhack007

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: fixing the PHY address for the ESP32-ETHERNET-KIT-VE board from 0 to 1, which is the only modification in the changeset.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[softhack007]

@coderabbitai please find the original commit that added the ethernet configuration that is subject of this PR. Also check if there were any other tickets that either justify the previous PHY address, or state problems. Do we have evidence that suggests the previous configuration was needed for some users? If yes, it might be better to keep the old values and add a fresh one with the suggested PHY=1 ?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

I'll dig into the git history and related issues right away.

---

🏁 Script executed:

#!/bin/bash
# Find original commit that added ESP32-ETHERNET-KIT-VE to network.cpp
git log --follow --all --oneline wled00/network.cpp | head -30

# Search for when KIT_VE or KIT-VE was added
git log --follow --all -S "KIT_VE\|KIT-VE\|ETHERNET_KIT" --oneline wled00/network.cpp

# Show the actual diff when KIT-VE was introduced
git log --follow --all -S "KIT_VE" --oneline -- wled00/network.cpp | head -5

Length of output: 1767

---

🏁 Script executed:

#!/bin/bash
# Search GitHub for related issues mentioning ESP32-ETHERNET-KIT or KIT-VE or PHY address
gh issue list --repo wled/WLED --state all --search "ESP32-ETHERNET-KIT" --limit 20
gh issue list --repo wled/WLED --state all --search "KIT-VE ethernet" --limit 20
gh issue list --repo wled/WLED --state all --search "PHY address ethernet" --limit 20

Length of output: 2543

---

🏁 Script executed:

#!/bin/bash
# Search for the specific issue `#2591` mentioned in the PR
gh issue view 2591 --repo wled/WLED

Length of output: 579

---

Let me dig deeper into the commit history and issue comments.

---

🏁 Script executed:

#!/bin/bash
# Search all commits for KIT-VE or KIT_VE addition
git log --all --oneline -S "KIT_VE" -- wled00/network.cpp
git log --all --oneline -S "KIT-VE" -- wled00/network.cpp
git log --all --oneline -S "ETHERNET_KIT" -- wled00/network.cpp

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Get comments on issue `#2591`
gh issue view 2591 --repo wled/WLED --comments

# Search for PRs related to KIT-VE or ESP32-Ethernet-Kit
gh pr list --repo wled/WLED --state all --search "KIT-VE" --limit 10
gh pr list --repo wled/WLED --state all --search "ESP32-ETHERNET-KIT ethernet" --limit 10

Length of output: 7623

---

Let me check the current file content around the KIT-VE entry and find the original adding commit more carefully.

---

🏁 Script executed:

#!/bin/bash
# Look at the KIT-VE section in network.cpp
rg -n "KIT.VE\|ETHERNET_KIT\|eth_address" wled00/network.cpp -C 5

# Try to find the original commit that added KIT-VE using git log with grep
git log --all --oneline --grep="KIT" | head -20
git log --all --oneline --grep="ethernet kit\|Ethernet Kit\|ethernet-kit\|KIT.VE" -i | head -20

# Also look at git log by Aircoookie around the time of issue `#2591` (2021-2022)
git log --all --oneline --author="Aircoookie" --after="2021-01-01" --before="2022-06-01" | head -30

Length of output: 2155

---

@softhack007: Here is a complete analysis of the history and related evidence.

---

Original Commit

The entry was introduced in commit a517f0df ("Add ESP32-ETHERNET-KIT-VE type") by Aircoookie, added directly in response to #2591. Aircoookie himself acknowledged the uncertainty at the time, writing in the issue: "It is possible that I got the pin definitions wrong, or that something else in the code needs to be changed that I am not anticipating right now, since your board uses a different PHY (ethernet interface) from all other Ethernet boards supported so far."

---

Evidence from Issue #2591 (All Reports Confirm Failure with PHY=0)

Every user who tested the ESP32-ETHERNET-KIT-VE profile reported the exact same failure mode — link LEDs lit, but no DHCP/IP obtained and no working Ethernet — which is precisely the symptom of a wrong PHY address:

• Roelof626 (original reporter): board connected via Ethernet (LEDs on) but never got an IP address.
• martymcbro: confirmed the same failure with v0.14.4, serial log shows initE: Attempting ETH config: 7 but no successful ETH.begin() — and then settings being reset to "none" on reboot.
• heyitsyang: confirmed the same problem with v0.15.0.

Not a single user ever confirmed that the PHY=0 entry worked. The issue has remained open since it was created.

---

External Documentation Unanimously Confirms PHY=1

The arduino-esp32 project (issue #3554, from 2019) explicitly states: "The phy address for the IP101 on the ethernet kit is 1."

Espressif's official ESP32-Ethernet-Kit v1.2 documentation describes the allocation of ESP32 MAC pins to the IP101GRI PHY under RMII, and all official ESP-IDF examples use CONFIG_EXAMPLE_ETH_PHY_ADDR=1.

There is no version of this board (V1.0, V1.1, V1.2) for which PHY=0 is documented or expected to work.

---

Conclusion: No Need for a Separate Entry

There is no evidence that PHY=0 was ever intentional, verified, or needed by any user. It was a speculative addition that was broken from day one. Keeping a PHY=0 entry would only cause confusion for users selecting between two profiles where one has never worked.

The correct approach is exactly what this PR does: simply correct the existing entry from eth_address = 0 to eth_address = 1. There is no justification for adding a second entry — the old value was a plain bug, not an alternative hardware variant.

[softhack007]

It seems to work for boards tested by the PR author, and the rabbit agrees the old config was "wrong from day 1". Agreed to merge, it should also be cherry-picked into 16_x and 0_15_x branches.

[DedeHai]

schematic has PHY address 0 set high for all versions. so this checks out.

[DedeHai]

@Techman749 thanks for fixing and testing this many years old issue

[netmindz]

Had this been cherry picked @DedeHai ?

[softhack007]

Had this been cherry picked @DedeHai ?

@netmindz I just did the cherry picking.

[DedeHai]

forgot to cherry pick :)

[Techman749]

Thank you for including this fork! I've had this board running WLED since 2023 and thought I was just doing something wrong. Figured I'd actually take a stab at figuring out the root cause. Glad to have solved it and find it was something this simple. Thanks for everything you guys do for this project!