SSL error while sending messages (IDFGH-1803)

[vtunr]

I did a stresstest with the lib (100+ message per second), and responding to those messages, with MQTT over TLS, using the lib from esp-idf v3.3-RC. After half a minute or a minute, sending stop working while receiving still does :

I (7575542) ABL_CLOUD: Recv AT+SETLED 1 o 0 on topic_1 E (7575542) esp-tls: write error :-27648: I (7575542) MQTT_LIB: Publish CMD OK on topic_2 (id: 58888) E (7575552) TRANS_SSL: esp_tls_conn_write error, errno=Success I (7575562) MQTT_LIB: WM : 2996 E (7575562) MQTT_CLIENT: Error write data or timeout, written len = -27648 E (7575572) MQTT_CLIENT: Error to public data to topic=topic_2, qos=1 I (7575572) ABL_CLOUD: Recv AT+SETLED 2 o 0 on topic_1 E (7575582) MQTT_LIB: Publish failed, can't send packet E (7575602) esp-tls: write error :-80: E (7575602) TRANS_SSL: esp_tls_conn_write error, errno=Connection reset by peer E (7575612) MQTT_CLIENT: Error write data or timeout, written len = -80 E (7575612) MQTT_CLIENT: Error to public data to topic=topic_2 qos=1 E (7575622) MQTT_LIB: Publish failed, can't send packet

Any idea where this could come from ? Let me know if you need more information.

[david-cermak]

Could you please update the esp-mqtt to the latest master and repeat the test there? IDF-3.3 points to f08f3b678717865234637164a29ed3a63e756ca7 which is a bit older veriosn and some fixes have been committed since.

Which mqtt broker you use? For example mosquitto is very fault tolerant, but google cloud might disconnect on faulty resends (one of the fixes). Also seeing from the log that the library doesn't abort connection when write fail, very strange (moreover as you say when receiving still works ok..)

I have tested ssl connection with local mosquitto sending/receiving approx 130 messages per second, so issue seen so far.

[vtunr]

For the broker, we're using rabbitMQ. Updated to latest esp-mqtt and it seems the problem disappeared. Though, I have new problems :

• Over WiFi :

I (246458) wifi: bcn_timout,ap_probe_send_start I (247358) SENSOR: ----- I (247358) PM_2012: PM1=1, PM25=1, PM10=2 I (247358) IDT: 0.00, 543042.62, 0.00, 400.00, 0 I (247358) SHT30b: temp:26.22, hum:33.12 I (247368) WUHAN_CO2: co2:1430 I (248368) SENSOR: ----- I (248368) PM_2012: PM1=1, PM25=1, PM10=2 I (248368) IDT: 0.00, 543042.62, 0.00, 400.00, 0 I (248368) SHT30b: temp:26.22, hum:33.10 I (248378) WUHAN_CO2: co2:1430 I (248958) wifi: ap_probe_send over, resett wifi status to disassoc I (248958) wifi: state: run -> init (c800) I (248968) wifi: pm stop, total sleep time: 27104509 us / 63111800 us   I (248978) wifi: new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1 E (248978) esp-tls: write error :-78: E (248978) TRANS_SSL: esp_tls_conn_write error, errno=Software caused connection abort E (248988) MQTT_CLIENT: Error write data or timeout, written len = -78, errno=113 E (248998) MQTT_CLIENT: Error to public data I (249008) ABL_CLOUD: Disconnected I (249008) MQTT_LIB: WM : 2980 W (249008) TRANS_SSL: Poll timeout or error, errno=Bad file number, fd=60, timeout_ms=10000 E (249018) MQTT_CLIENT: Error write data or timeout, written len = -1, errno=9 E (249038) MQTT_CLIENT: Error sending ping E (249038) MQTT_CLIENT: Can't send ping, disconnected I (249038) ABL_CLOUD: Disconnected I (249048) MQTT_LIB: WM : 2980 I (249098) wifi: new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1 I (249098) wifi: state: init -> auth (b0) I (249108) wifi: state: auth -> assoc (0) I (249108) wifi: state: assoc -> run (10) I (249128) wifi: connected with airboxlab_timecapsule, channel 1, HT20, bssid = 0c:51:01:e7:29:e2 I (249128) wifi: pm start, type: 1

• On ethernet :

  abort() was called at PC 0x40082dc3 on core 0

Updating ESP-IDF to latest is too big of a change (tried it, but needs some modification on our own code). Is this an issue you already encountered ? At 60 message/s, problem is there, at 30, no problem.

[david-cermak]

No, I haven't seen such error before. Could this be related to free heap space? Could you print out the heap info? As for the Ethernet issue, it looks like it crashed in wifi lib. Is wifi initialised in this test? Can you please test it without wifi?

[david-cermak]

Hi @vtunr

Could you please share some simple code that could be used to reproduce this issue? Thanks!

[david-cermak]

@vtunr Any updates?

[vtunr]

@david-cermak No update, i'll try to check if it's still happens on latest SDK, but it's probably going to be in a week or so.

[david-cermak]

okay, thanks for the feedback!

[david-cermak]

@vtunr Closing as not reproducible, please feel free to reopen if the issue still appears with the current version.