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(pcb=@200102e4, data=@20005920, 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 <[email protected]> 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:42 [email protected] <mailto:[email protected]> > > <[email protected] <mailto:[email protected]>> 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 > > > [email protected] <mailto:[email protected]> > > > https://lists.nongnu.org/mailman/listinfo/lwip-users > > > > > > > > > _______________________________________________ > > lwip-users mailing list > > [email protected] <mailto:[email protected]> > > https://lists.nongnu.org/mailman/listinfo/lwip-users > > > > > > _______________________________________________ > > lwip-users mailing list > > [email protected] > > https://lists.nongnu.org/mailman/listinfo/lwip-users > > > > _______________________________________________ > lwip-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users
handshake.pcapng
Description: Binary data
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
