Almost there with network/sta2eth example, but DNS issue? (ESP-IDF v5.2.2)

[Siddle34]

Hi there all,

Well I've been at this a few days and it's been endless frustration! However, I think I'm gradually ironing out the issues. I believe I have identified the problem area (I hope, anyway). For reference, I should mention that I am using VS Code as my IDE with the official ESP-IDF extension. The version of the ESP-IDF api is v5.2.2.

So, to the network/sta2eth example. This example shows how to use the ESP32 board as a bridge between a device such as a Router AP connected to the ESP32's WiFi Station and a PC connected to the ESP32's Ethernet port. (At least, in my case it's Ethernet, but you can choose USB instead of Ethernet if you're using an ESP32-S3, for example.)

I have the following hardware test setup:

[Raspberry Pi 5 (running Ubuntu) Ethernet] --wire--> [ESP32 Ethernet --sta2eth--> ESP32 WiFi Station] --wireless--> [Router AP (w/internet)]

I have tried this using an ESP32 with an external W5500 Ethernet module (over SPI), and also an ESP32 ETH01 which has an on-board LAN8720 Ethernet chip (over RMII). Naturally, sdkconfig ends up looking quite different for each of these cases (I use VS Code's quite user-friendly implementation of menuconfig), and I'm pretty confident I've got this largely correct, having tried some of the more basic ESP-IDF examples with good success.

Unfortunately however, I am running into a similar problem regardless of what hardware I use.

We can essentially divide the sta2eth example code into two parts. The first part is the WiFi provisioning, i.e. the manner in which you securely convey the WiFi credentials (ssid and password) from the Raspberry Pi to the ESP32. I use the so-called "manual" method. The way this works is that after powering up, the ESP32 runs a DHCP server and a HTTP server. It assigns itself an IP address of 192.168.4.1 and the Raspberry Pi client an IP of 192.168.4.2. When the user browses to http://wifi.settings, it serves up a simple web form containing text fields for ssid and password. The user fills them out appropriately, and clicks a connect button.

So far so good. This all seems to work well.

(And at this point I ought to mention that I have disabled the Ubuntu distro's default choice of network interface management tools, i.e. network-manager because I think it's interfering in generally unhelpful ways. Consequently, I'm now using basic ifconfig (with the ifup and ifdown wrappers), dhcpcd and wpa_supplicant. I should also mention that I always shut off the Raspberry Pi's own WiFi because it's an unnecessary distraction.)

We now reach the second part of the sta2eth code. It calls a software reset on itself and then re-runs, this time recognising that the provisioning has already been accomplished, and what's now required is the establishment of a pass-through link between the ESP32's Ethernet interface and its Wifi interface (in Station mode) such that an "invisible" bridge will be formed between the Raspberry Pi and the Router AP (which is itself connected to the internet). In theory at least, the Pi will be connected to the outside world!

Not quite. But the good news is that I see this:

Code: Select all

someone@someone-desktop:/media/someone/ESD-USB$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.208  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2a00:23c4:b441:3501:63ff:2d38:690:cb6e  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::2ecf:67ff:fe3c:3480  prefixlen 64  scopeid 0x20<link>
        ether 2c:cf:67:3c:34:80  txqueuelen 1000  (Ethernet)
        RX packets 5885  bytes 631087 (631.0 KB)
        RX errors 0  dropped 5  overruns 0  frame 0
        TX packets 6116  bytes 582685 (582.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 115

And this works:

Code: Select all

someone@someone-desktop:/media/someone/ESD-USB$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=9.90 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=15.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=14.1 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=116 time=18.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=116 time=13.0 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=116 time=15.8 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=116 time=16.1 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=116 time=20.9 ms
^C
--- 8.8.8.8 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8008ms
rtt min/avg/max/mdev = 9.896/14.938/20.946/3.222 ms

But this DOESN'T WORK:

Code: Select all

someone@someone-desktop:/media/someone/ESD-USB$ ping google.com
ping: google.com: Temporary failure in name resolution

Websites fail to load!

For reference, here is my /etc/network/interfaces file:

Code: Select all

someone@someone-desktop:/media/someone/ESD-USB$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
dns-nameservers 192.168.4.1 95.85.95.85 8.8.8.8 1.1.1.1
# dns-nameservers 95.85.95.85 8.8.8.8 1.1.1.1

So I think the problem is DNS-related, either to do with the function of the DHCP client (the Raspberry Pi) or of the DHCP server (the Router AP/ESP32). I know that apart from distributing IP addresses within a network, a DHCP server configures the subnet mask, default gateway, and DNS server information. And because the Raspberry Pi doesn't seem to be able to resolve google.com into 8.8.8.8, doesn't this indicate a DNS problem?

Apologies for the long-winded explanation. Has anyone any ideas as to what might help? By the way, I had to #define MODIFY_DHCP_MSGS 1 in the ethernet_iface.c file in order to ensure the Pi was assigned an IPv4 address on the local network.

I would be most grateful if someone could help me finally get this working! Cheers.