Hi Which CPU do you use and how much free RAM do you have? Ethernet frame size is 1514, how is your PBUF_POOL_BUFSIZE size?
niedz., 27 sty 2019 o 20:40 Paweł <[email protected]> napisał(a): > 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 > > _______________________________________________ > lwip-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users -- pozdrawiam tomek
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
