Networking Using ppp and esp32?

[jouellnyc]

Howdy All

Running "MicroPython v1.22.2-dirty on 2024-02-21" on a T-Display-S3 from https://github.com/russhughes/s3lcd

My goal is to route traffic from this T-Display-S3 to a Raspbery Pi Zero and bring it to the office which runs WPA2 Enterprise.
I have achieved this sort of thing wirelessly - https://github.com/jouellnyc/wpa-ent-mschapv2-bridge and it worked well.

Now, I am now testing at home with dupont cables and PPP:

|T-Display-S3| ===(UART)====>      |Raspbery Pi Zero| ===(Wireless)=====>|Local DNS server|
    10.0.5.3                       10.0.5.1/192.168.0.247                  192.168.0.193

The T-Display-S3 and Pi Zero maintain a very good ppp connection. Pings back and forth are working.

However, an HTTP call from the T-Display-S3 to google fails.
Whether I try to route the packets unNATed as '10.0.5.3' or with NAT/iptables as '192.168.0.247' it ends with OSError -202.

#same result with urequests
import mrequests
url = "http://www.google.com/"
headers = {
    "User-Agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Mobile/15E148 Safari/604.1"
}
response = mrequests.get(url, headers=headers)
Resolving host address...
Traceback (most recent call last):
  File "<stdin>", line 6, in <module>
  File "mrequests/mrequests.py", line 30, in get
  File "mrequests/mrequests.py", line 313, in request
OSError: -202

line 313 is:

ai = socket.getaddrinfo(ctx.host, ctx.port, 0, socket.SOCK_STREAM)[0]
which is where I believe the problem is.

Firstly, note that I have routes on 192.168.0.193 (pi-hole DNS allowing traffic to that subnet) back to 10.0.5.X and the T-Display-S3 can ping 192.168.0.193, as well as send and 'receive' DNS queries as per tcpdumps.

However it appears the T-Display-S3 either ignores them or does not properly 'consume' the reply:

#tcpdumping incoming NAT'ed packets on the DNS server (192.168.0.193)

root@raspi4b:~# tcpdump -i eth0 port 53 -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:59:20.947870 IP 192.168.0.247.35944 > 192.168.0.193.53: 8596+ A? www.google.com. (32)                                                                                                      
21:59:20.948456 IP 192.168.0.193.53 > 192.168.0.247.35944: 8596 1/0/0 A 142.250.65.164 (48)                                                                                                   


#tcpdumping UNAT'ed packets from DNS server back to T-Display-S3 

root@pizero2wb:~# tcpdump -i ppp0 not port 22 -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
22:06:11.723325 IP 10.0.5.3.8382 > 192.168.0.193.53: 558+ A? www.google.com. (32)
22:06:11.725034 IP 192.168.0.193.53 > 10.0.5.3.8382: 558 1/0/0 A 142.251.40.228 (48)

NOTE: If I simply connect the T-Display-S3 to my wifi the HTTP calls work and everything is great, so it seems like the problem is fundamental to PPP. I realize this isn't exactly a normal setup, but it seems like I am pretty close.

I am not so much looking for a solution as a second opinion.
Any thoughts / advice welcome.

[jouellnyc]

I thought this had to do with UART buffer size.

I was able to have a server on the T-Display-S3 esp32 and have it serve a 9k "file" (just a bunch of h's) :

import usocket as socket
import machine

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
port=8211
s.bind(('0.0.0.0',port))  # Replace 80 with your desired port
s.listen(5)
print('HTTP server listening on port', port)

while True:
    conn, addr = s.accept()
    print('Connected by', addr)
    request = conn.recv(1024)
    request = request.decode()
    request_method, path, protocol, *rest = request.split()
    if request_method == 'GET' and path == '/':
        h_string = "h" * 10000
        response = f"HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\nHello, world {h_string}"
        response  = response.encode()
    else:
        response = b'HTTP/1.1 404 Not Found\r\nContent-Type: text/plain\r\n\r\nResource not found'
    conn.send(response)
    conn.close()

The Raspbery Pi Zero (now as a client) can retrieve the data just fine:

root@pizero2wb:~# wget -S -d http://10.0.5.3:8211/
DEBUG output created by Wget 1.21.3 on linux-gnueabihf.

Reading HSTS entries from /root/.wget-hsts
URI encoding = ‘UTF-8’
Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8)
--2024-09-20 17:23:43--  http://10.0.5.3:8211/
Connecting to 10.0.5.3:8211... connected.
Created socket 3.
Releasing 0x0094cc40 (new refcount 0).
Deleting unused 0x0094cc40.

---request begin---
GET / HTTP/1.1
Host: 10.0.5.3:8211
User-Agent: Wget/1.21.3
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response... 
---response begin---
HTTP/1.1 200 OK
Content-Type: text/html

---response end---

  HTTP/1.1 200 OK
  Content-Type: text/html
Registered socket 3 for persistent reuse.
Length: unspecified [text/html]
Saving to: ‘index.html.4’

index.html.4                                        [ <=>                                                                                                  ]   9.78K  --.-KB/s    in 0.09s   

2024-09-20 17:23:43 (113 KB/s) - ‘index.html.4’ saved [10013]

At least right now, for some reason it's not working well 'the other way'. The T-Display-S3 as a client seems not to be able to connect and get the data as initially stated, however if I create an HTTP server on the The Raspbery Pi Zero and T-Display-S3 is a socket client it works up until I do get to a certain response size:

>>> import string
>>> q_string = string.ascii_lowercase * 22 # fail
>>> len(q_string)
572
>>> q_string
'abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz'

This ends with the client getting "An error occurred: [Errno 116] ETIMEDOUT"

Whereas using a slightly smaller response just works:

>>> q_string2 = string.ascii_lowercase * 21 # works
>>> q_string2
'abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz'
>>> len(q_string2)
546

>>> import utime
import usocket as socket

def connect_to_server(host='192.168.1.100', port=8000):
    try:
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.settimeout(5.0)
        s.connect((host, port))
        print(f"Connected to {host}:{port}")
        message = "Hello, server!"
        s.send(message.encode())
        print(f"Sent: {message}")
        data = s.recv(1024)
        print(f"Received: {data.decode()}")
        s.close()
    except OSError as e:
        print(f"An error occurred: {e}")

host='10.0.5.1'
port=8001

connect_to_server(host=host, port=port)
Connected to 10.0.5.1:8001
14
Sent: Hello, server!
Received: abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz

So it seems like T-Display-S3 as tcp client over ppp has trouble getting past receiving more that 546 bytes. I will pursue modifying the MTU.

[bidrohini]

Since the MTU defines the maximum packet size that can be sent over the network , you can try adjusting the MTU on both the T-Display-S3 and Raspberry Pi Zero.

[jouellnyc]

Yes. Thanks for the reply. I reduced it on the Zero to a few values lower than 546 on ppp0 (from default of 1500) , just poking around:

ip link set dev ppp0  mtu 546
ip link set dev ppp0  mtu 526
ip link set dev ppp0  mtu 135

I didn't find a way to modify the esp32's however.

Same behavior I'm afraid.

[jouellnyc]

I can get to Google and another test site via IP after putting back the default MTU at 1500. Both those sites had pages less than 500 bytes or so. A friend of mine put a web server out there on the 'net with a 600 and then a 674 byte /index.html to test. The T Display got both fine. Unless I missed something, it now seems more like a DNS related issue vs MTU per se.

[jouellnyc]

Tcpdump on ppp0 (un-NAT side) of the Pi Zero with T-Display-S3 trying to connect to Google :

url = "https://www.google.com/"
import mrequests
headers = {
    "User-Agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Mobile/15E148 Safari/604.1"
}
response = mrequests.get(url, headers=headers)
data = response.text

Resolving host address...
Traceback (most recent call last):
  File "<stdin>", line 6, in <module>
  File "mrequests/mrequests.py", line 30, in get
  File "mrequests/mrequests.py", line 313, in request
OSError: -202

captured DNS port 53 but seems OK. The packets do not seem to be very large:

Ditto for the wlan0 capture (NAT side)

[jouellnyc]

Swapping out the T-display physically and putting an esp32 in its place with psram running:

MicroPython v1.23.0 on 2024-06-02; Generic ESP32S3 module with Octal-SPIRAM with ESP32S3

That also seems not to be able to connect given the same ppp setup.

>>> import machine
uart = machine.UART(2, baudrate=1000000, tx=13, rx=14)
import network
ppp = network.PPP(uart)
ppp.active(True)
ppp.connect()
True
>>> ppp.ifconfig(('10.0.5.3', '10.0.5.1', '255.255.255.255', '192.168.0.193'))   
>>> print(ppp.ifconfig())
('10.0.5.3', '10.0.5.1', '255.255.255.255', '192.168.0.193')
>>> url = "https://www.google.com/"
import mrequests
headers = {
    "User-Agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Mobile/15E148 Safari/604.1"
}
response = mrequests.get(url, headers=headers)
data = response.text

Traceback (most recent call last):
  File "<stdin>", line 6, in <module>
  File "mrequests/mrequests.py", line 30, in get
  File "mrequests/mrequests.py", line 313, in request
OSError: -202
>>> 

Manually checking DNS:

>>> socket.getaddrinfo("www.google.com", 443, 0, socket.SOCK_STREAM)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: -202

>>> socket.getaddrinfo("www.google.com", 80, 0, socket.SOCK_STREAM)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: -202
>>> 

Pointing to google's dns does not make a difference:

>>> ppp.ifconfig(('10.0.5.3', '10.0.5.1', '255.255.255.255', '8.8.8.8'))   
>>> 
>>> print(ppp.ifconfig())

('10.0.5.3', '10.0.5.1', '255.255.255.255', '8.8.8.8')
>>> 

>>> socket.getaddrinfo("www.google.com", 443, 0, socket.SOCK_STREAM)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: -202

>>> socket.getaddrinfo("www.google.com", 80, 0, socket.SOCK_STREAM)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: -202

Not too sure at this point.

[sophiedegran]

Jouell thanks for your investigation (like your process)
I remenber this problem a long time ago (if this is one), it was on dns response missing the end caracter or something like that..
I will try to check for something more precise..

[jouellnyc]

Thanks @sophiedegran! That would be great. Very curious to see.

And coincidentally, I was just about to post, as it does not seem like:

1. urequests or mrequests are supporting proxies so that route seems like it's not going to work.

2. Wiznet / esp32 / other hardware options seems like a possibly https://github.com/Ayyoubzadeh/ESP32-Wiznet-W5500-Micropython but does not appear https is working.

FYI for others googling - these Ethernet options maybe a path:

• Ayyoubzadeh/ESP32-Wiznet-W5500-Micropython: Connecting ESP32 to W5500 using micropython
  https://github.com/Ayyoubzadeh/ESP32-Wiznet-W5500-Micropython

• emard/esp32lan8720: ESP32+LAN8720 wired ethernet micropython example
  https://github.com/emard/esp32lan8720

• przemobe/micropy-ENC28J60: ENC28J60 Ethernet chip driver for MicroPython (RP2)
  https://github.com/przemobe/micropy-ENC28J60/tree/main

For fun I have a serial to ethernet converter on the way, so was going to see if any change in behavior.