No DNS entries when using Ethernet

[kuppe234]

Hello,
I am using ESPEasy in conjunction with Ethernet. Wifi is not in use, there is no connection.

With the DHCP request, the DNS servers are also transmitted (visible in the log), but the variables (dns0_cache and dns1_cache) are not set and therefore 0.0.0.0. This is due to an error in "src/src/DataStructs/EthernetEventData.cpp". "WiFi" must be changed to "ETH" there.

See "git diff":

diff --git a/src/src/DataStructs/EthernetEventData.cpp b/src/src/DataStructs/EthernetEventData.cpp
index 01a8e25b8..592177d92 100644
--- a/src/src/DataStructs/EthernetEventData.cpp
+++ b/src/src/DataStructs/EthernetEventData.cpp
@@ -5,7 +5,7 @@
 #include "../ESPEasyCore/ESPEasy_Log.h"
 #include "../Helpers/Networking.h"
 
-#include <WiFi.h>
+#include <ETH.h>
 
 // Bit numbers for Eth status
 #define ESPEASY_ETH_CONNECTED               0
@@ -99,11 +99,11 @@ void EthernetEventData_t::setEthConnected() {
 bool EthernetEventData_t::setEthServicesInitialized() {
   if (!unprocessedEthEvents() && !EthServicesInitialized()) {
     if (EthGotIP() && EthConnected()) {
-      if (valid_DNS_address(WiFi.dnsIP(0))) {
-        dns0_cache = WiFi.dnsIP(0);
+      if (valid_DNS_address(ETH.dnsIP(0))) {
+        dns0_cache = ETH.dnsIP(0);
       }
-      if (valid_DNS_address(WiFi.dnsIP(1))) {
-        dns1_cache = WiFi.dnsIP(1);
+      if (valid_DNS_address(ETH.dnsIP(1))) {
+        dns1_cache = ETH.dnsIP(1);
       }
 
       #ifndef BUILD_NO_DEBUG

Greetings, kuppe.

[tonhuisman]

What ESPEasy release are you running?
Have you tried to install the latest available from http://td-er.nl/espeasy/latest/ ? As a bug in that area has been fixed recently. (⚠️ be careful when connecting Ethernet and USB at the same time to your ESP, especially when using PoE! Better unplug the Ethernet cable when connecting to USB ⚠️)

[kuppe234]

I'm using the latest release, selfbuild:

Build:⋄	20230613 - Mega32
System Libraries:⋄	ESP32 SDK 4.4.4.20230310
Git Build:⋄	mega_2ee2073
Plugin Count:⋄	48 [Normal]
Build Origin:	Self built
Build Time:⋄	Jun 13 2023 12:33:51
Binary Filename:⋄	ESP_Easy_mega_20230613_normal_ESP32_4M316k_ETH
Build Platform:⋄	Linux-6.3.5-200.fc38.x86_64-x86_64-with-glibc2.37
Git HEAD:⋄	mega_2ee2073

[TD-er]

Yep, looks like a copy/paste bug...
I will have a look at it.

Only one thing that's a bit confusing here.
The reason I need to keep track of the cache for DNS is that it might get mangled when you change the WiFi mode and/or if you have an IPv6 DHCP6 server running in your network.
That last one might overwrite the DNS server fields with the first 32 bits of the IPv6 prefix.

Since the DNS entries are shared among ETH and WiFi (really bad design decision of LWIP), I wonder how much differences it might make here between checking dns entries for ETH and WiFi.
But apparently it does, or else you hadn't posted a diff here :)

[TD-er]

Made a PR for this:
#4703

[kuppe234]

I don't have wifi here at all. Therefore, no DNS entries can be configured via Wifi DHCP.

[TD-er]

I understand, but what I meant was that in LWIP (the IP stack) the entry for the DNS servers for all interfaces are being shared.
So I was kinda 'thinking out loud' why/how it would even matter whether you query the DNS server entries from ETH or WiFi.

But anyhow, I made the changes you suggested.

If you could have a look (either at the code, or the compiled GH Actions build) at my PR to see if I messed up or that it is now fixed, then I can merge it.

[kuppe234]

1 second after receiving the DHCP data (with correct DNS entry) both DNS variables were set to 0.0.0.0.
Thanks for the change in git, now everything works perfectly.

[TD-er]

Yep, the DNS fields will be cleared when WiFi.mode() changes.
Very frustrating.

I'm thinking about adding very strict networking modes in ESPEasy, so WiFi doesn't even need to be started when a user needs Ethernet only.

Right now I try to make it as dynamic as possible, so if the Ethernet plug is removed it will start WiFi etc.
But since it does take a while to setup Ethernet, WiFi is already started now and that's causing issues like these.

But that's a major overhaul of ESPEasy code, so I'm holding that off a bit as it is a good guarantee for lots of other side issues when doing such a major change and I need to free up quite a lot of time to spend on it continuously.