ESP32S2: Implement TCP Server bindings

[hierophect]

This PR adds a few new features to support running a TCP server on the ESP32-S2:

1. Adds bind, listen and accept, which allow connecting to remote sockets and sending/receiving data from them.
2. Removes the property that all sockets of type SOCK_STREAM automatically use MbedTLS instead of the LWIP socket API, and makes that decision on the fly based on what functions are used first.
3. Adds in additional logic to the various send and receive functions to determine when to use TLS vs LWIP.

The differentiation between sockets that use TLS and those that don't is still a bit hacky. Right now, it's determined by what functions the socket calls first - if you use connect after initialization, it'll become a TLS socket and will be ineligible for any other uses. Otherwise (ie, calling bind or sendto first) it becomes a regular socket. I'd like to eventually improve this to allow connect without TLS, possibly by putting the TLS init in the SSL wrapper step. We could also consider moving all TLS functionality to a separate module (possibly a duplicate Socket based API) instead of having both kinds of operation under the hood here.

Tested on a Saola 1 Wrover. Test programs below:

• Run this on the ESP32S2: https://gist.github.com/hierophect/5bb6133a69f8395841531013d46d2703
• Run this on your host machine, obtaining the IP address from what the ESP32S2 prints in the first sketch, or by monitoring the UART debug output on a Saola board: https://gist.github.com/hierophect/b6bcdca453166038307b40d5647d9352

Resolves #3724
Resolves #3836

[tannewt]

Thanks for the PR! Sorry I left these pending. Thanks for the ping!

[tannewt]

@krittick want to test this PR?

[krittick]

@krittick want to test this PR?

Sure, would love to. Will try to get to it later today.

[hierophect]

Does the CI failure have to do with my code?

subprocess.CalledProcessError: Command '['/opt/hostedtoolcache/Python/3.8.7/x64/bin/python', '-m', 'virtualenv', '/home/runner/work/circuitpython/circuitpython/.idf_tools/python_env/idf4.2_py3.8_env']' returned non-zero exit status 1.

My changes don't affect anything related to this, as far as I can tell?

[tannewt]

I don't think so. Dan and Jeff would have a better idea of the CI state atm.

[hierophect]

@tannewt looks like CI passed this time, should ready for re-review

[tannewt]

This looks good to me! Thank you! I'm holding the approval so this is merged in for 6.2 rather than 6.1. @dhalbert can merge post-6.1

[hierophect]

This looks good to me! Thank you! I'm holding the approval so this is merged in for 6.2 rather than 6.1. @dhalbert can merge post-6.1

Sounds good. I have the TLS server separation PR finished and ready to go as soon as this gets merged, so we could potentially get both of them into the same release.

[dhalbert]

Approving and merging as requested.

Discord merge approval

[netroy]

Hey @hierophect,
I've been running a hacked together code for NTP sync on an ESP32S2 board, and it has stopped working since this change.
git bisect has located the breaking commit from this PR. I believe it might be the changes in the socketpool code.
Reverting the merge commit fixed the issue for me.

Here is the code

import struct
import time
import rtc
import socketpool
import wifi

TZ_OFFSET = 3600
NTP_TO_UNIX_EPOCH = 2_208_988_800  # 1970-01-01 00:00:00
BILLION = 1_000_000_000

wifi.radio.connect(ssid=secrets["ssid"], password=secrets["password"])
pool = socketpool.SocketPool(wifi.radio)
packet = bytearray(48)
packet[0] = 0b00100011

for i in range(1, len(packet)):
  packet[i] = 0

with pool.socket(pool.AF_INET, pool.SOCK_DGRAM) as sock:
  sock.sendto(packet, ("pool.ntp.org", 123))
  sock.recvfrom_into(packet)
  destination = time.monotonic_ns()

seconds = struct.unpack_from("!I", packet, offset=len(packet) - 8)[0]
monotonic_start = seconds - NTP_TO_UNIX_EPOCH - (destination // BILLION)

rtc.RTC().datetime = time.localtime(time.monotonic_ns() // BILLION + monotonic_start + TZ_OFFSET)

The call sock.recvfrom_into seems to be the one that fails with an EAGAIN.
Unfortunately my C foo isn't up to the mark to be able to debug this any further.
But, if you could point out what the issue might be (in this PR, or my code), I'd be really grateful.

Cheers :)

[hierophect]

Hi @netroy, an issue with this PR was that when it expanded the timeout system to support non-blocking calls, it inadvertently set the default timeout of a socket to 0 instead of the Cpython default of None (ie infinite timeout). #4049 will change back to None, but until then you can use settimeout(None) to extend the timeout yourself. I think that should resolve your problem, but feel free to follow up with an issue if it doesn't.

[tannewt]

@hierophect Maybe we should fix this outside of #4049 so we can get it in faster.

[hierophect]

@tannewt nah it's already in, this problem was one of the simple ones. I do think we can go ahead and merge #4049. The big issue is what's going on in #4061 which I'm still hacking at but can put in a different PR

[hierophect]

Wait I probably read that wrong, you mean change the default timeout in a new PR so we can take more time on #4049?