Hi, This is TI CC1312R microcontroller (Cortex M4F, 80 kB RAM, 352 kB Flash). uC has got some crypto accelerators built in which I plan to use after establishing proper communication. At the moment about 20 kB RAM free (I'm sure that I could make some additional savings). PBUF_POOL_BUFSIZE 1516 bytes (TCP_MSS 1460). MBEDTLS_SSL_MAX_CONTENT_LEN and MBEDTLS_MPI_MAX_SIZE are set to 4096.
pon., 28 sty 2019 o 08:24 tomek wilkxt <[email protected]> napisał(a): > 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
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
