事情已经过去快一周了吧，继上次修复 maixpy k210 的 esp8285 at 通信后，突然遇到泽畔大大问，要不要做 ussl 的支持？

评估了一下各方的实现，想了一下自己也刚好在做网络层的优化和处理，况且 micropython 在 stm32 、 esp32 上的也有对应的实现，那就添加实现进去吧，选取了 mbedtls 版本的 ussl 模块，实现相关文件如下。

这里说一下 ussl 的工作机制。

首先建立在 micropython 的 network 架构下的 socket 模块，提供了关键的 steam->write 和 steam->read 基础接口，实际上就是继承一个抽象 steam 对象的接口。

因此 ussl 提供了 wrap_socket 用来提升 socket 的功能，从而支持 https 的访问。

我们看一下 micropython 的实例就知道了。

  1. try:
  2.     import usocket as _socket
  3. except:
  4.     import _socket
  5. try:
  6.     import ussl as ssl
  7. except:
  8.     import ssl
  10. def main(use_stream=True):
  11.     s = _socket.socket()
  13.     ai = _socket.getaddrinfo("google.com", 443)
  14.     print("Address infos:", ai)
  15.     addr = ai[0][-1]
  17.     print("Connect address:", addr)
  18.     s.connect(addr)
  20.     s = ssl.wrap_socket(s)
  21.     print(s)
  23.     if use_stream:
  24.         # Both CPython and MicroPython SSLSocket objects support read() and
  25.         # write() methods.
  26.         s.write(b"GET / HTTP/1.0\r\n\r\n")
  27.         print(s.read(4096))
  28.     else:
  29.         # MicroPython SSLSocket objects implement only stream interface, not
  30.         # socket interface
  31.         s.send(b"GET / HTTP/1.0\r\n\r\n")
  32.         print(s.recv(4096))
  34.     s.close()
  36. main()

实现的最终结果如下，不过目前的实测效果距离商业使用，保守来讲，还有很大的优化空间，主要在核心函数和配置方面要改善性能。

  • esp32 的效果

  • k210 的效果

MaixPy k210 采用 components/micropython/CMakeLists.txt 来管理 micropython 的编译命令。

所以在不脱离主流的基础上，在 micropython-ulab 的配置后面继续添加如下配置。

  1.     if(1 OR CONFIG_MICROPY_SSL_MBEDTLS)
  2.         list(APPEND ADD_INCLUDE "${mpy_core_dir}/lib/mbedtls/include")
  3.         set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -DMBEDTLS_CONFIG_FILE='\"${mpy_port_dir}/src/mbedtls/include/mbedtls_config.h\"'")
  4.         # message(${CMAKE_C_FLAGS})
  5.         append_srcs_dir(ADD_SRCS "port/src/mbedtls")
  6.         append_srcs_dir(ADD_SRCS "core/lib/mbedtls/library")
  7.         list(REMOVE_ITEM ADD_SRCS "${mpy_core_dir}/lib/mbedtls/library/net_sockets.c")
  8.     endif()

稍微解释一下

  • 将 mbedtls/include 和 mbedtls/library 添加到环境中，并排除 net_sockets.c 的实现，问题下述。

  • 给 CMAKE_C_FLAGS 添加 -DMBEDTLS_CONFIG_FILE 自定义的 mbedtls 配置文件，从而屏蔽内置的 config.h 。（奇怪的是 add_definitions 不 work ，就直接用 set 了）
  1. #if !defined(MBEDTLS_CONFIG_FILE)
  2. #include "mbedtls/config.h"
  3. #else
  4. #include MBEDTLS_CONFIG_FILE
  5. #endif

所以现在把代码编译了进去，就完成了大部分的移植，是不是很简单？

修改记录在这里，可供参考。

当然，事情不会这么顺利的，在没有进行专门配置的时候，启动模块是可以的，现在开始实践发起一次 get https 网站的请求，测试 python code 如下：

  2. wCli = MicroWebCli('https://tcc.taobao.com/cc/json/mobile_tel_segment.htm?tel=13631786501')
  3. # wCli = MicroWebCli('https://www.baifubao.com/callback?cmd=1059&callback=phone&phone=13631786501')
  4. # wCli = MicroWebCli('https://github.com')
  5. # wCli = MicroWebCli('https://ssl.logink.cn/')
  6. # wCli = MicroWebCli('https://cn.bing.com/?FORM=Z9FD1')
  7. # wCli = MicroWebCli('https://www.sojson.com')
  8. # wCli = MicroWebCli('https://www.baidu.com')
  10. while True:
  11.     try:
  12.         print('GET %s' % wCli.URL)
  13.         wCli.OpenRequest()
  14.         buf  = memoryview(bytearray(1024))
  15.         resp = wCli.GetResponse()
  16.         if resp.IsSuccess() :
  17.           while not resp.IsClosed() :
  18.             x = resp.ReadContentInto(buf)
  19.             if x < len(buf) :
  20.               buf = buf[:x]
  21.             print(bytes(buf))
  22.           print('GET success with "%s" content type' % resp.GetContentType())
  23.         else :
  24.           print('GET return %d code (%s)' % (resp.GetStatusCode(), resp.GetStatusMessage()))
  25.     except Exception as E:
  26.         print(E)
  27.     time.sleep(2)

Gather entropy_len bytes of entropy to seed state

mbedtls_ctr_drbg_seed returned -52 或者-0x0034

错误解释：

MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED        -0x0034  /**< The entropy source failed. */

原因：

给mbedtls提供的熵源不够混乱，应该用硬件随机数发生器。

解决：

mbedtls\config.h

解决方案可以参考

https://blog.csdn.net/liaofeifly/article/details/88899655

mbedtls_hardware_poll 实现可以参考 esp32 、stm32 的，如下是我后来实践到 k210 的，这个函数只会在发起链接的时候调用。

  2. #include <stdlib.h>
  3. #include <stdio.h>
  4. #include "rng.h"
  6. #if !defined(MBEDTLS_CONFIG_FILE)
  7. #include "mbedtls/config.h"
  8. #else
  9. #include MBEDTLS_CONFIG_FILE
  10. #endif
  12. #include "mphalport.h"
  14. int os_get_random(unsigned char *buf, size_t len)
  15. {
  16.     int i, j;
  17.     unsigned long tmp;
  18.  
  19.     for (i = 0; i < ((len + 3) & ~3) / 4; i++) {
  20.         tmp = rng_get() + systick_current_millis();
  21.  
  22.         for (j = 0; j < 4; j++) {
  23.             if ((i * 4 + j) < len) {
  24.                 buf[i * 4 + j] = (uint8_t)(tmp >> (j * 8));
  25.             } else {
  26.                 break;
  27.             }
  28.         }
  29.     }
  30.  
  31.     return 0;
  32. }
  34. int mbedtls_hardware_poll( void *data, unsigned char *output, size_t len, size_t *olen )
  35. {
  36.     int res = os_get_random(output, len);
  37.     *olen = len;
  38.     return 0;
  39. }
  41. // int mbedtls_hardware_poll(void *data, unsigned char *output, size_t len, size_t *olen) {
  42. //     uint32_t val;
  43. //     int n = 0;
  44. //     *olen = len;
  45. //     while (len--) {
  46. //         if (!n) {
  47. //             val = rng_get();
  48. //             n = 4;
  49. //         }
  50. //         *output++ = val;
  51. //         val >>= 8;
  52. //         --n;
  53. //     }
  54. //     return 0;
  55. // }

错误类型是

这个问题我看了很久，因为上来就给我当头一棒，任何 https 的访问都布星。

那就奇了怪了，然后我开了 debug 开关，开到等级 4 后。

  1.     #ifdef MBEDTLS_DEBUG_C
  2.     // Debug level (0-4)
  3.     mbedtls_debug_set_threshold(4);
  4.     #endif

发现 TM 有在流动数据，而且是在工作的，而且看数据发现是正常工作的。

那么开了 debug 和没有开 debug 的区别在哪里呢？

可以想象的是 debug 肯定会对程序执行产生一些细微的差距，最后通过几次 debug 的后定位到是这个函数的延时保障了程序的执行。

看起来是不是很奇怪？为什么呢？如果在这里简单的延时就会产生下述的效果。

也就是请求时好时坏，如果知道是需要延时的话，那么又该延时多少呢？

此时交给❤名侦探登场❤，真相只有一个！

首先函数来自于 f_send 操作，这个肯定是个回调，然后定位它。

  2. void mbedtls_ssl_set_bio( mbedtls_ssl_context *ssl,
  3.         void *p_bio,
  4.         mbedtls_ssl_send_t *f_send,
  5.         mbedtls_ssl_recv_t *f_recv,
  6.         mbedtls_ssl_recv_timeout_t *f_recv_timeout )
  7. {
  8.     ssl->p_bio          = p_bio;
  9.     ssl->f_send         = f_send;
  10.     ssl->f_recv         = f_recv;
  11.     ssl->f_recv_timeout = f_recv_timeout;
  12. }

说明来自上层，那么继续，定位到 /home/junhuanchen/MaixPy/components/micropython/core/extmod/modussl_mbedtls.c 。

  1.     mbedtls_ssl_set_bio(&o->ssl, &o->sock, _mbedtls_ssl_send, _mbedtls_ssl_recv, NULL);

说明回调的是 _mbedtls_ssl_send 函数，如下。

  2. STATIC int _mbedtls_ssl_send(void *ctx, const byte *buf, size_t len) {
  3.     mp_obj_t sock = *(mp_obj_t*)ctx;
  5.     const mp_stream_p_t *sock_stream = mp_get_stream(sock);
  6.     int err;
  7.     mp_uint_t out_sz = sock_stream->write(sock, buf, len, &err);
  8.     if (out_sz == MP_STREAM_ERROR) {
  9.         if (mp_is_nonblocking_error(err)) {
  10.             return MBEDTLS_ERR_SSL_WANT_WRITE;
  11.         }
  12.         return -err;
  13.     } else {
  14.         return out_sz;
  15.     }
  16. }

经过测试发现，延时不应该上在 sock_stream->write 之前，而是之后，那么这说明什么问题呢？

如果要解决问题，是可以在这里添加延时解决问题，但是这里是问题的源头吗？显然不是。

判断有二

  • esp32 为什么没有这个问题？
  • 这个模块的位置在 micropython core 体系下，说明有大量的实例支撑它们的逻辑正确性。

那么说明问题并不是这个地方导致的，在这个 micropython 的体系里，这时候只能说明一个问题，是网卡的 sock_stream->write 请求过快返回导致的问题。

而我在用的是 ESP8285 的 AT 网卡，这就可以联想到 esp_send 的工作机制不一定符合标准 socket 工作时序。

为什么呢？

因为 AT 的请求只需要将数据发送过去即可完成传输，但传输正确与否请求这端不直接参与，这与其他芯片的工作到链路层发送数据的机制不同，所以就会提前返回。

如果我的假设是正确的，那么我应该把问题定位到这里 components/micropython/port/src/standard_lib/network/esp8285/modesp8285.c 之中的 esp8285_socket_send 函数。

  2. STATIC mp_uint_t esp8285_socket_send(mod_network_socket_obj_t *socket, const byte *buf, mp_uint_t len, int *_errno) {
  4. 	if((mp_obj_type_t*)&mod_network_nic_type_esp8285 != mp_obj_get_type(MP_OBJ_TO_PTR(socket->nic)))
  5. 	{
  6. 		*_errno = MP_EPIPE;
  7. 		return MP_STREAM_ERROR;
  8. 	}
  9. 	nic_obj_t* self = MP_OBJ_TO_PTR(socket->nic);
  10.     if(socket->peer_closed)
  11.     {
  12.         *_errno = MP_ENOTCONN;
  13.         return MP_STREAM_ERROR;
  14.     }
  15.     Buffer_Clear(&self->esp8285.buffer);//clear receive buffer
  16.     socket->first_read_after_write = true;
  17. 	if(0 == esp_send(&self->esp8285,(const char*)buf,len, (uint32_t)(socket->timeout*1000) ) )
  18. 	{
  19. 		*_errno = MP_EPIPE;
  20. 		return MP_STREAM_ERROR;
  21. 	}
  22.     // printk("%s len %d\r\n", __func__, len);
  23.     mp_hal_delay_us(len * 50); // maybe 50 us time required to send per byte
  24.     // vTaskDelay(len / portTICK_PERIOD_MS);
  25.     return len;
  26. }

在这里我做了一个假设性的 timing 测试，假设为了修复它与其他芯片同步的工作时序，那么我应该在发送数据后进行一段时间的延时，但这个延时是多久呢？

我现在通信在用的波特率都是 921600 ，在这个假设可行的情况下，我假定每个字节发送到对端需要的时间为 100 us 即 mp_hal_delay_us(len * 50); ，以此进行测试。

结论是实测 100 us 恢复正常工作，表示已经修复成功，那么就结束了吗？

还没，我们应该还要继续确定，真正预期的延时应该是多少？

接着二分法到 50 us 也成功。

继续二分法到 25 us 也成功。

继续二分法到 10 us 却不成功。// 虚伪二分

那么结论也有个大概了，考虑到 921600 的速率过快，我原本思考要么就 25 us 最优方案。

但后来发现，每次请求的数据并不会应该这个值而有所改善性能，反而可能会存在小概率请求失败，那既然没影响，应该保守设置到 50 us 比较合理。

修改记录在此

此时修改的位置非常合理，一方面不破坏 esp32 spi 那端的网卡，另一方面也不破坏 micropython core 的代码，从而比较优雅的解决问题。

实测 https 的网站都有如下，不过 github.com 的 hostname 经常获取不到，dns 炸裂

wCli = MicroWebCli(‘https://tcc.taobao.com/cc/json/mobile_tel_segment.htm?tel=13631786501‘)
wCli = MicroWebCli(‘https://www.baifubao.com/callback?cmd=1059&callback=phone&phone=13631786501‘)
wCli = MicroWebCli(‘https://github.com‘)
wCli = MicroWebCli(‘https://ssl.logink.cn/‘)
wCli = MicroWebCli(‘https://cn.bing.com/?FORM=Z9FD1‘)
wCli = MicroWebCli(‘https://www.sojson.com‘)
wCli = MicroWebCli(‘https://www.baidu.com‘)

另外 HTTPS 的访问速度没有想象的快，从建立链接到收发数据就需要差不多 20s，相比 HTTP 的 10 秒一次请求，这中间有很大的优化空间。

简单判断跟加密解密的软实现函数的效率有关，也可能跟目标网站的响应速度以及对应的 TLS 传输协议有关，可以进一步优化 mbedtls 的配置文件。

需要实测真实用户的 https 的使用环境才能进一步优化。

2020年5月11日 junhuanchen 留

版权声明：本文为juwan原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://www.cnblogs.com/juwan/p/12870705.html