Re: [lwip-users] lwIP with mbedTLS

[Jan Menzel]

mbedtls is based on a synchronous design schema and WONT_READ is (as
WONT_WRITE) the "error message" to signal the library that the requested
data is currently not available. It is absolutely normal, that this
happens from time to time. I've done multiple implementations using
mbedtls all using its default socket API interface incl. one using lwip
2.0. WONT_READ is just something you have to return to the library in
the recv() function to indicate, that the requested data is currently
not available and the socket is not configured/allowed to block until it
is. On the application side you will get the same "error" (eg from
mbedtls_ssl_handshake()), which just means that you have to retry.
        Unfortunately I did not yet had the opportunity to try the new altcp
implementation so that I cannot give any hints there...

        Jan

On 27.01.2019 20:39, Paweł wrote:
> Hi Jan,
> I encountered memory problems in the beginning (cpu hang - insufficient
> heap memory) but after little tuning the application works well.
> Sometimes when Server Hello message is delayed a bit (what I'm contantly
> observing on Wireshark) handshake will just end with WANT_READ error
> before it could even read this message.
> Also I don't see any memory problems on mbedTLS debug and no errors on
> lwip_stats.
> Please look at logs below. I'm attaching also Wireshark packets with
> Handshake beginning. Packet 6510 is a client hello message (compared
> with Wireshark). Look when it is ready, and when it is sent out on
> interface - just after returning error on parsing Server Hello which
> couldn't be there as Client Hello is still in buffer! 
> This is why I supposed threading problems.
> 
> tcp_output_segment: 6509:6509
> tcp_enqueue_flags: queueing 6509:6510 (0x2)
> +-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
> tcp_parseopt: MSS
> SYN-SENT: ackno 6510 pcb->snd_nxt 6510 unacked 6509
> => handshake
> client state: 0
> => flush output
> <= flush output
> client state: 1
> => flush output
> <= flush output
> => write client hello
> client hello, max version: [3:3]
> client hello, session id len.: 0
> client hello, add ciphersuite: c030
> client hello, got 1 ciphersuites (excluding SCSVs)
> adding EMPTY_RENEGOTIATION_INFO_SCSV
> client hello, compress len.: 1
> client hello, compress alg.: 0
> client hello, adding signature_algorithms extension
> client hello, adding supported_elliptic_curves extension
> client hello, adding supported_point_formats extension
> client hello, adding session ticket extension
> client hello, total extension length: 48
> => write handshake message
> => write record
> output record: msgtype = 22, version = [3:3], msglen = 97
> => flush output
> message length: 102, out_left: 102
> tcp_write(address@hidden, address@hidden, len=102, apiflags=1)
> *tcp_write: queueing 6510:6612*
> ssl->f_send() returned 102 (-0xffffff9a)
> <= flush output
> <= write record
> <= write handshake message
> <= write client hello
> client state: 2
> => flush output
> <= flush output
> => parse server hello
> => read record
> => fetch input
> in_left: 0, nb_want: 5
>  while( ssl->in_left < nb_want )
> f_recv
> in_left: 0, nb_want: 5, ret: -26880
> <= handshake
> *tcp_output_segment: 6510:6612*
> 
> niedz., 27 sty 2019 o 20:07 Jan Menzel <address@hidden
> <mailto:address@hidden>> napisał(a):
> 
>     Hi Pawel!
> 
>     On 27.01.2019 14:08, Paweł wrote:
>     [...]
>     > I'm missing two messages: Client Key Exchange and then Session ticket.
>     [...]
> 
>     Thats where the expensive part has been done. I'd suggest to check your
>     memory setup. You need a lot of memory to validate the servers
>     identity...
> 
>             Jan
> 
>     > Regards,
>     > Pawel
>     >
>     > niedz., 27 sty 2019 o 13:address@hidden
>     <mailto:address@hidden> <mailto:address@hidden
>     <mailto:address@hidden>>
>     > <address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>> napisał(a):
>     >
>     >     Am 27.01.2019 um 10:44 schrieb Paweł:
>     >     > Hello,
>     >     > I'm trying to build an application using lwIP and mbedTLS.
>     My goal
>     >     is a
>     >     > secure MQTT connection.
>     >     > I'm sure that MQTT without security layer works properly. lwIP
>     >     works in
>     >     > sys mode.
>     >     > I started of course with ALTCP layer and I can succesfully parse
>     >     > certificate using code:
>     >     > mqttClientInfo.tls_config = altcp_tls_create_config_client(cert,
>     >     > sizeof(cert));
>     >     >
>     >     > After mbedTLS tuning (choosing cipher method, etc.) I can see on
>     >     > Wireshark proper Client Hello and Server Hello messages.
>     Then Server
>     >     > Hello Done, Certificate and Server Key Exchange message is
>     coming (no
>     >     > outgoing Client Key Exchange), but from observations I see that
>     >     messages
>     >     > from Server aren't properly handled by lwIP core.
>     >     > On console I can see that mbedTLS switched to parsing Server
>     Hello
>     >     > message but in fetch method input f_recv function (which is
>     a pointer
>     >     > to altcp_mbedtls_bio_recv) is
>     returning MBEDTLS_ERR_SSL_WANT_READ
>     >     which
>     >     > means that there is nothing to read. What is interesting after
>     >     this fail
>     >     > lwIP signals receiving a TCP packet, with Server Hello
>     message (I
>     >     > cross-checked sequence numbers with Wireshark). So I digged
>     deeper
>     >     and
>     >     > found out that everything in mbedTLS is called from lwIP thread
>     >     context,
>     >     > so secure layer can't wait for messages. I realized that
>     when I was
>     >     > trying to implement f_recv_timeout function.
>     >
>     >     I'm a bit confused: are you using the mqtt client provided with
>     >     lwIP? If
>     >     so, TLS should just work. No need to implement f_recv_timeout.
>     >
>     >     Regards,
>     >     Simon
>     >
>     >     >
>     >     > Questions:
>     >     > 1. Does anybody met similiar problems?
>     >     > 2. Can I check for incoming messages in mbedTLS, handle them
>     >     normally in
>     >     > lwIP core and come back to mbedTLS functions? Maybe there is a
>     >     need for
>     >     > separating threads for two of them?
>     >     >
>     >     > I encountered many problems during mbedTLS implementations
>     but all of
>     >     > them were affordable (missing defines, memory problems,
>     etc.) but
>     >     this
>     >     > time I have no idea what to do next.
>     >     >
>     >     > Regards,
>     >     > Pawel
>     >     >
>     >     > _______________________________________________
>     >     > lwip-users mailing list
>     >     > address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>
>     >     > https://lists.nongnu.org/mailman/listinfo/lwip-users
>     >     >
>     >
>     >
>     >     _______________________________________________
>     >     lwip-users mailing list
>     >    address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>
>     >     https://lists.nongnu.org/mailman/listinfo/lwip-users
>     >
>     >
>     > _______________________________________________
>     > lwip-users mailing list
>     > address@hidden <mailto:address@hidden>
>     > https://lists.nongnu.org/mailman/listinfo/lwip-users
>     >
> 
>     _______________________________________________
>     lwip-users mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>