lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] lwIP with mbedTLS


From: Paweł
Subject: Re: [lwip-users] lwIP with mbedTLS
Date: Sun, 27 Jan 2019 20:39:18 +0100

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> 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 address@hidden <mailto:address@hidden>
> <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>
>     > 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
>

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

Attachment: handshake.pcapng
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]