I think this is pretty cool,@JAndrassy! I would be careful about howavailable() on SSL connections works with this. IIRC, when I did the SSL server/clientavailable andconnected were the 2 big stumbling blocks.

I think this is pretty cool,@JAndrassy! I would be careful about howavailable() on SSL connections works with this. IIRC, when I did the SSL server/clientavailable andconnected were the 2 big stumbling blocks.

Thank you@earlephilhower . I am not sure if it is useful, but at least it shows the difference between Servers in Arduino libraries and in ESP libraries.

I attempted to test the SSL server, but telnet-ssl could not connected. I will test it again if this PR should be merged.

@earlephilhower, multiple copies of BearSSL::WiFiClientSecure for one connection are not in sync. so ArduinoWiFiServer doesn't work because the copy it holds still returns available() based on _recvapp_len, even if the copy returned before already read the data from the connection. if the data is read again esp8266 crashes.

axTLS works (the copies share the context object)

multiple copies of BearSSL::WiFiClientSecure for one connection are not in sync.

From what I understand, there's only one copy for each client, given by::accept(). Am I wrong ?

multiple copies of BearSSL::WiFiClientSecure for one connection are not in sync.

From what I understand, there's only one copy for each client, given by::accept(). Am I wrong ?

the concept of Arduino Client is that multiple copies of WiFiClient/EthernetClient (created as return values or parameters passed by copy) can interact with the same TCP connection. WiFiClient should be only a pointer to internal representation. In ESP8266WiFi library the WiFiClient does it with ClientContext. the axTLS does it very very nice with the std shared pointer to SSLContext.

(I think this strange concept of Arduino API classes has origin in simulating Java objects behaviour for some sketch source compatibility with Processing framework. so no-> or& only.)

In the ArduinoWiFiServer template the array of 'monitored' WiFiClient objects has instance pointing to the connection and server.available() returns a copy always when data are available for it. So the WiFiClient object in the array
must have the same information about count of data available as the copy which reads the data.

the concept of Arduino Client is that multiple copies of WiFiClient/EthernetClient (created as return values or parameters passed by copy) can interact with the same TCP connection.

Right, I think we agree, I was meaning: "From what I understand, there's only oneTCP instance for each client, given by ::accept().".
Do we really agree ? If we do I don't see the reason why several SSL clients should not work.

However maybe you should call on every occasion and even if it's useless::connected()and::available() onevery client occurence to make the TLS state machine move forward. All of them, but of course only theindex one is returned to the user.

the concept of Arduino Client is that multiple copies of WiFiClient/EthernetClient (created as return values or parameters passed by copy) can interact with the same TCP connection.

Right, I think we agree, I was meaning: "From what I understand, there's only oneTCP instance for each client, given by ::accept().".
Do we really agree ? If we do I don't see the reason why several SSL clients should not work.

However maybe you should call on every occasion and even if it's useless::connected()and::available() onevery client occurence to make the TLS state machine move forward. All of them, but of course only theindex one is returned to the user.

for BearSSL the problem are the two copies of WiFiClientSecure for the same connection. one in the array of monitored clients and second in sketch filled at return from server.available(). the sketch reads data over its copy. the buffer counter _recvapp_len gets to 0. but the instance in the array still has the original value of _recvapp_len and returns the client again as if it has data available.

available() calls bool() for every monitored client and bool() calls connected.

for BearSSL the problem are the two copies of WiFiClientSecure for the same connection

That is true. I wasn't aware.WiFiClientSecure's context must move away to an external context for your class to work with it in the arduino way.
Like withWiFiClient which is stateless and pointing to aClientContext which holds the TCP connection.

Can you try with#7680 ?

@d-a-v

connectedClients[i].status() == ESTABLISHED is never true, because status() is not redirected to Ctx.

and second client gets

juraj@nuc ~ $ telnet-ssl -z ssl 192.168.1.117 2323Trying 192.168.1.117...SSL: reason(0)SSL_Connect: Input/output error

for the second client "BSSL:_connectSSLServerRSA: OOM error" is logged
WiFiServerSecureAxTLS could handle 4 clients

Thanks to@earlephilhower 's suggestion in gitterserver.setBufferSizes() (512 was not enough, but 1024 is OK),
and his ssl server example from which I copied keys andserver.setECCert(),
and also thanks to a fix onssl::status() not properly routed to ssl context in#7680 thatI'm about to I just push,
I could run your PR with 3 SSL clients and it's working well (showing two below):

$ telnet-ssl -z ssl 10.0.1.144 2323Trying 10.0.1.144...SSL: Server has a self-signed certificateSSL: unknown Issuer: /C=AU/ST=Some-State/O=Internet Widgits Pty LtdConnected to 10.0.1.144.Escape character is '^]'.totoecho: tototitiecho: titi

$ telnet-ssl -z ssl 10.0.1.144 2323Trying 10.0.1.144...SSL: Server has a self-signed certificateSSL: unknown Issuer: /C=AU/ST=Some-State/O=Internet Widgits Pty LtdConnected to 10.0.1.144.Escape character is '^]'.tototiti

patched example:

  // Attach the server private cert/key combo  BearSSL::X509List *serverCertList = new BearSSL::X509List(server_cert);  BearSSL::PrivateKey *serverPrivKey = new BearSSL::PrivateKey(server_private_key);  server.setECCert(serverCertList, BR_KEYTYPE_KEYX|BR_KEYTYPE_SIGN, serverPrivKey);  server.setBufferSizes(1024,1024);  server.begin();

Approving but to merge after#7680 (needed for this PR when SSL is used)
(or after#7680 is removed from this PR)

#7680 is removed