Replies: 6 comments 4 replies
-
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) :
The Raspbery Pi Zero (now as a client) can retrieve the data just fine:
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:
This ends with the client getting "An error occurred: [Errno 116] ETIMEDOUT" Whereas using a slightly smaller response just works:
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Tcpdump on ppp0 (un-NAT side) of the Pi Zero with T-Display-S3 trying to connect to Google :
captured DNS port 53 but seems OK. The packets do not seem to be very large: |
Beta Was this translation helpful? Give feedback.
-
Swapping out the T-display physically and putting an esp32 in its place with psram running:
That also seems not to be able to connect given the same ppp setup.
Manually checking DNS:
Pointing to google's dns does not make a difference:
Not too sure at this point. |
Beta Was this translation helpful? Give feedback.
-
I believe the root cause was 'me'. I setup a different pi zero w/an esp32. It was a while back but the only thing I can even think of is I misconfigured I have the needed setup and configs listed here: Life is grand now:
Hooray |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
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.
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:
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.
Beta Was this translation helpful? Give feedback.
All reactions