air724+阿里云OTA升级失败，SSL报错code = -29056

发布于 2021-11-08 10:08:19 浏览：1887 订阅该版

硬件配置:
主控：STM32H750VBT6
4G模块：air724UG
问题描述：
使用阿里云IOT ota进行升级的时候失败，报错提示如下：

[D/ali.udp]  ok
[D/ali.udp]   . Verifying peer X.509 certificate..
[D/ali.udp] certificate verification result: 0x00
[dbg] _http_send_header(171): REQUEST (Length: 336 Bytes)
> GET /ota/ac4b8bdf1f6222ea201f950368802b8f/ckvo1jmgd0000378brsx8fj5i.bin?Expires=1636345014&OSSAccessKeyId=LTAI4G1TuWwSirnbAzUHfL3e&Signature=%2BqHlgX9xXnI6173wyV3SCFTf86s%3D HTTP/1.1
> Host: iotx-ota.oss-cn-shanghai.aliyuncs.com
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Encoding: gzip, deflate
> 
。。。。
[E/ali.udp] ssl recv error: code = -29056, err_str = 'SSL - Verification of the messag'
[err] httpclient_common(558): httpclient_recv_response is error,ret = -8

请问有人碰到过这样的问题吗，是如何解决的？不吝赐教，谢谢！

3 个回答

李肯陪你玩赚嵌入式 认证专家 2021-11-08

2022年度和2023年度RT-Thread社区优秀开源布道师，COC深圳城市开发者社区主理人，专注于嵌入式物联网的架构设计

看你的这个错误，猜想应该是使用mbedtls库进行TLS通讯。
找了下源码，这个错误属于TLS数据交互过程中，数据包的MAC校验错误。

发现这个错误码返回还是应该挺多的

提供几个思路，仅供参考：
1.把mbedtls源码中的DEBUG日志打开，找一找更为关键的log信息，重点看下TLS交互到哪里；
2.抓取终端与后台的TLS交互报文，使用wireshark工具分析报文，TLS的交互逻辑就非常清晰了；
3.参考阿里云的demo，自己的代码有没有特别的改动？

spoor 2021-11-08

这家伙很懒，什么也没写！

packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1649 => decrypt buf
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1727 dumping ‘additional data used for AEAD’ (13 bytes)
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1727 0000: 00 00 00 00 00 00 00 01 17 03 03 05 78 ………..packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1734 dumping ‘IV used’ (12 bytes)
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1734 0000: f0 bb 59 19 b5 a5 70 48 08 ed e5 cb ..Y…pH…packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1735 dumping ‘TAG used’ (16 bytes)
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1735 0000: 32 c8 4e 32 f8 e1 4c 79 9f ec a1 0c 31 26 bd 49 2.N2..Ly…packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1748 mbedtls_cipher_auth_decrypt() returned -25344 (-0x6300)
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c3855 ssl_decrypt_buf() returned -29056 (-0x7180)
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c4317 => send alert message
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c4318 send alert level=2 message=20
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c2867 => write record
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1313 => encrypt buf
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1324 dumping ‘before encrypt: output payload’ (2 bytes)
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1324 0000: 02 14 ..
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1442 dumping ‘additional data used for AEAD’ (13 bytes)
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1442 0000: 00 00 00 00 00 00 00 02 15 03 03 00 02 ………..packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1459 dumping ‘IV used’ (8 bytes)
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1459 0000: 00 00 00 00 00 00 00 02 ……..
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1471 before encrypt: msglen = 10, including 0 bytes of padding
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1497 dumping ‘after encrypt: tag’ (16 bytes)
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1497 0000: 36 95 16 35 22 62 6f 1a 1f dd a9 89 95 28 c4 2b 6..5”bo….packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c1635 <= encrypt buf
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c3013 output record: msgtype = 21, version = [3:3], msglen = 26
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c3016 dumping ‘output record sent to network’ (31 bytes)
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c3016 0000: 15 03 03 00 1a 00 00 00 00 00 00 00 02 33 71 36 ………..packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c3016 0010: 95 16 35 22 62 6f 1a 1f dd a9 89 95 28 c4 2b ..5”bo…..packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c2574 => flush output
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c2593 message length: 31, out_left: 31
[D/AT] sendline: 0000-0020: 41 54 2B 43 49 50 53 45 4E 44 3D 31 2C 33 31 AT+CIPSEND=1,31
[D/AT] recvline: 0000-0020: 0D 0A ..
[D/AT] recvline: 0000-0020: 3E >
[D/AT] sendline: 0000-0020: 15 03 03 00 1A 00 00 00 00 00 00 00 02 33 71 36 FFFFFF95 16 35 22 62 6F 1A 1F FFFFFFDD FFFFFFA9 FFFFFF89 FFFFFF95 28 FFFFFFC4 2B ………….3q6..5”bo……(.+
[D/AT] recvline: 0000-0020: 20 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 0D 0A ………
[D/AT] recvline: 0000-0020: 44 41 54 41 20 41 43 43 45 50 54 3A 31 2C 33 31 0D 0A DATA ACCEPT:1,31..
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c2599 ssl->f_send() returned 31 (-0xffffffe1)
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c2626 <= flush output
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c3025 <= write record
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c4330 <= send alert message
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c3912 mbedtls_ssl_read_record_layer() returned -29056 (-0x7180)
packages/mbedtls-v2.7.10.1/mbedtls/library/ssl_tls.c7100 mbedtls_ssl_read_record() returned -29056 (-0x7180)
[E/ali.udp] ssl recv error: code = -29056, err_str = ‘SSL - Verification of the messag’
[err] httpclient_common(558): httpclient_recv_response is error,ret = -8

看TLS的详细报文，最后发的alert message，还是不能确定是哪个路径的MBEDTLS_ERR_SSL_INVALID_MAC返回，要精确定位一下了

spoor 2021-11-08

这家伙很懒，什么也没写！

if defined(MBEDTLS_SSL_DTLS_BADMAC_LIMIT)

            if( ssl->conf->badmac_limit != 0 &&
                ++ssl->badmac_seen >= ssl->conf->badmac_limit )
            {
                MBEDTLS_SSL_DEBUG_MSG( 1, ( "too many records with bad MAC" ) );
                return( MBEDTLS_ERR_SSL_INVALID_MAC );
            }

endif

应该是这个地方了，还是没明白啥原因，要研究一下源码了，哭晕在厕所啊

李肯陪你玩赚嵌入式 2021-11-08

2022年度和2023年度RT-Thread社区优秀开源布道师，COC深圳城市开发者社区主理人，专注于嵌入式物联网的架构设计

@spoor 查了点资料，仔细了解了下这个 MBEDTLS_SSL_DTLS_BADMAC_LIMIT 配置项，主要是记录BADMAC的情况，次数多了，证明当前的通讯链路不是很文档，常有报文异常出现。
从逻辑上说，这个选项是可以禁用的。
下面的参考网页中搜索MBEDTLS_SSL_DTLS_BADMAC_LIMIT
参考1：mbedtls官方提及的这个选项的简略说明；
参考2：RT-Thread mbedtls软件包对mbedtls进行ROM/RAM优化的建议。
基于上面的资料，我建议你载mbedtls_config.h里面禁用这个选项，试试看？

还有一个问题，你的终端环境，能正常与其他TLS服务器交互（握手，收发数据，关闭全流程）吗？

spoor 2021-11-08

这家伙很懒，什么也没写！

@recan 有可能和链路信号质量有关，因为用的是合宙luat，测试的天线是随便淘宝买的，但是观察信号质量好像还可以，接外接天线信号强度达到31,99，不确定的是持续的信号质量情况。由于合宙原厂建议的是天线需要与整个终端设备（包括外壳，4G硬件模块自研）进行阻抗匹配、还有驻波的调优，才能在信号弱的时候信号质量也可以。
确实在调试的过程中出现构造带连里云IOT的过程中出现publish失败的情况（频繁），在OTA升级的器件，握手过后，有大段的ssl密文通讯报文，报文大小惊人，是有丢包的可能，进而出现MBEDTLS_ERR_SSL_INVALID_MAC报错。
目前把AT日志，TLS日志屏蔽掉，偶尔可以下载bin文件升级包

event_handle|090 :: publish success, packet-id=1
event_handle|090 :: publish success, packet-id=2
event_handle|066 :: subscribe success, packet-id=3
event_handle|066 :: subscribe success, packet-id=4
event_handle|066 :: subscribe success, packet-id=5
event_handle|066 :: subscribe success, packet-id=6

< {
< “code”: “1000”,
< “data”: {
< “size”: 507328,
< “sign”: “65fa9223116e136adebf50d3b0dc87f7”,
< “version”: “1.1”,
< “signMethod”: “Md5”,
< “url”: “https: //iotx-ota.oss-cn-shanghai.aliyuncs.com/ota/ac4b8bdf1f6222ea201f950368802b8f/ckvo1jmgd0000378brsx8fj5i.bin?Expires=1636455127&OSSAccessKeyId=LTAI4G1TuWwSirnbAzUHfL3e&Signature=jcN%2B9VuFTkI6nrROXTWeNU4i95g%3D”,
< “md5”: “65fa9223116e136adebf50d3b0dc87f7”
< },
< “id”: 1636368727708,
< “message”: “success”
< }

[I/DBG] Start erase flash (download) partition!
[I/DBG] Erase flash (download) partition success!
[D/ali.udp] Loading the CA root certificate …
cert. version : 3
serial number : 04:00:00:00:00:01154B5AC3:94
issuer name : C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
subject name : C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
issued on : 1998-09-01 12:00:00
expires on : 2028-01-28 12:00:00
signed using : RSA with SHA1
RSA key size : 2048 bits
basic constraints : CA=true
key usage : Key Cert Sign, CRL Sign
[D/ali.udp] crt content:451
[D/ali.udp] ok (0 skipped)
[D/ali.udp] Connecting to /iotx-ota.oss-cn-shanghai.aliyuncs.com/443…
[D/ali.udp] ok
[D/ali.udp] . Setting up the SSL/TLS structure…
[D/ali.udp] ok
[D/ali.udp] Performing the SSL/TLS handshake…
[D/ali.udp] ok
[D/ali.udp] . Verifying peer X.509 certificate..
[D/ali.udp] certificate verification result: 0x00
[dbg] _http_send_header(171): REQUEST (Length: 336 Bytes)

GET /ota/ac4b8bdf1f6222ea201f950368802b8f/ckvo1jmgd0000378brsx8fj5i.bin?Expires=1636455127&OSSAccessKeyId=LTAI4G1TuWwSirnbAzUHfL3e&Signature=jcN%2B9VuFTkI6nrROXTWeNU4i95g%3D HTTP/1.1
Host: iotx-ota.oss-cn-shanghai.aliyuncs.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Encoding: gzip, deflate

[dbg] httpclient_recv_response(487): RESPONSE (Length: 32 Bytes)
< HTTP/1.1 200 OK
< Server: AliyunO

{
“id”: 0,
“params”: {
“step”: “0”,
“desc”: “Enter in downloading state”
}
}

[I/DBG] receive 999 bytes, total recieve: 507328 bytes
[I/DBG] receive 1998 bytes, total recieve: 507328 bytes
[I/DBG] receive 2997 bytes, total recieve: 507328 bytes
[I/DBG] receive 3996 bytes, total recieve: 507328 bytes
[I/DBG] receive 4995 bytes, total recieve: 507328 bytes

但是大多数时候是像这样：
[D/ali.udp] certificate verification result: 0x00

{
“id”: “0”,
“version”: “1.0”,
“params”: [
{
“attrKey”: “SYS_LP_SDK_VERSION”,
“attrValue”: “3.0.1”,
“domain”: “SYSTEM”
},
{
“attrKey”: “SYS_SDK_LANGUAGE”,
“attrValue”: “C”,
“domain”: “SYSTEM”
}
],
“method”: “thing.deviceinfo.update”
}

{
“id”: “1”,
“params”: {
“version”: “app-1.0.0-20180101.1000”
}
}

event_handle|090 :: publish success, packet-id=1
[E/ali.udp] ssl recv error: code = -29056, err_str = ‘SSL - Verification of the messag’
[err] iotx_mc_read_packet(541): mqtt read error, rc=-1
[err] iotx_mc_cycle(1517): readPacket error,result = -14
[err] _mqtt_cycle(1605): error occur rc=-14
[err] _mqtt_cycle(1605): error occur rc=-27
[err] _mqtt_cycle(1605): error occur rc=-27
[err] _mqtt_cycle(1605): error occur rc=-27
[err] _mqtt_cycle(1605): error occur rc=-27
[err] iotx_mc_keepalive(1859): network is disconnected!
event_handle|058 :: MQTT disconnect.
[E/at.clnt] execute command (AT+CIPSEND=0,31) failed!
[D/ali.udp] ssl_disconnect
[err] _mqtt_cycle(1605): error occur rc=-27
[err] _mqtt_cycle(1605): error occur rc=-27
[err] _mqtt_cycle(1605): error occur rc=-27
[err] _mqtt_cycle(1605): error occur rc=-27
[err] _mqtt_cycle(1605): error occur rc=-27
[err] _mqtt_cycle(1605): error occur rc=-27
[err] _mqtt_cycle(1605): error occur rc=-27
[err] _mqtt_cycle(1605): error occur rc=-27
[err] _mqtt_cycle(1605): error occur rc=-27
[err] _mqtt_cycle(1605): error occur rc=-27
[E/ali.udp] handle is NULL
[D/ali.udp] Loading the CA root certificate …
cert. version : 3
serial number : 04:00:00:00:00:01154B5AC3:94
issuer name : C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
subject name : C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
issued on : 1998-09-01 12:00:00
expires on : 2028-01-28 12:00:00
signed using : RSA with SHA1
RSA key size : 2048 bits
basic constraints : CA=true
key usage : Key Cert Sign, CRL Sign
[D/ali.udp] crt content:451
[D/ali.udp] ok (0 skipped)
[D/ali.udp] Connecting to /a1infjluu7l.iot-as-mqtt.cn-shanghai.aliyuncs.com/443…
[D/ali.udp] ok
[D/ali.udp] . Setting up the SSL/TLS structure…
[D/ali.udp] ok
[D/ali.udp] Performing the SSL/TLS handshake…
[D/ali.udp] ok
[D/ali.udp] . Verifying peer X.509 certificate..
[D/ali.udp] certificate verification result: 0x00
event_handle|062 :: MQTT reconnect.
event_handle|090 :: publish success, packet-id=2
所以初步判断，有可能是天线与4G模块的问题。

李肯陪你玩赚嵌入式 2021-11-08

2022年度和2023年度RT-Thread社区优秀开源布道师，COC深圳城市开发者社区主理人，专注于嵌入式物联网的架构设计

@spoor 这种有成功过的情况，而且是时而丢包出问题的情况；跟网络质量关系比较大；
根据经验来说，终端软件在软件层面上可操作的东西不多，毕竟也跟硬件网络有关系。
而且mbedtls本身的流程是跑得通的，只是偶发出问题。
倒是可以有个方向可以参考下：尝试把TLS交互的密钥套件限定为比较简单的，
减少TLS交互数据加解密的复杂度（TLS使用对称算法和非对称算法，属于计算密集型操作，非常耗CPU），
这样或许在一定程度上减少出错的概率，但这个密钥套件得看服务端支不支持弱一些的一些密钥套件。