完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
我有一个旧版本的SDK,3.1.2,与目前在该领域的设备的问题。我有一个无法解释的问题,其中我从“WICEDEJTCPILISTRAYRIDE”返回5007,表示一个无效的TLS记录。
TCP+TLS流在一种机制中被读取,其中文件通过手动打开套接字、建立TLS上下文、创建流、构建HTTP请求、将其发送到流、解析HTTP头响应、然后在一个时间内抓取二进制体1024字节而被读取。直到最后。 特别奇怪的是,这个代码在WiFi AP的95%上运行良好,但是在移动热点WiFi(包括iPhone 6S)上,它将通过下载在同一点上命中这个错误。该文件是~300 KB,错误将发生在80K,可重复地,总是在相同的长度通过流。 我在一个平台上运行,这个平台有点资源受限,有128KB的RAM。然而,它再次在一些WiFi AP上运行良好,而不是在其他人上。 我已经用NGiNX服务器测试了它,它使用16KB TLS记录和2KB TLS记录,每一个都使用“SSLBuffReSythSigy”参数,这两种情况都存在问题。 我正在调试硬件上运行它,但是没有遇到调试或与MALLC相关的断点或硬件故障。 据我所知,失败是` wiced_tls_receive_packet `,750号线,在打电话:结果= tls_get_next_record(上下文,&;记录,超时,tls_receive_packet_if_needed); 不幸的是,我不能走的更深,因为贝斯勒在3.1.2是二进制。 我不知道足够的关于TLS在想做调试的结果在` wiced_tls_receive_packet `。 关于为什么会发生这样的事情有什么想法吗? 以上来自于百度翻译 以下为原文 I am having an issue with an old version of the SDK, 3.1.2, with devices that are presently in the field. I am having an unexplained issue wherein I get return 5007 from `wiced_tcp_stream_read`, indicating an invalid TLS record. The TCP+TLS stream is being read in a mechanism whereby a file is downloaded by manually opening a socket, setting up a TLS context, creating a stream, constructing an HTTP request, sending it to the stream, parsing the HTTP header response, and then grabbing the binary body 1024 bytes at a time until the end. The particularly odd thing is that this code works fine on 95% of wifi AP's, but on a mobile hotspot wifi (including an iPhone 6S), it will hit this error at the same point through the download. The file is ~300KB, and the error will happen at ~80K, repeatably, always in the same length through stream. I am running on a platform that is *somewhat* resource constrained, with 128KB of RAM. However, again: it works fine on some WiFi AP's, and not on others. I have tested this with an nginx server that uses both 16KB TLS records and 2KB TLS records, per the `ssl_buffer_size` parameter, and the problem exists for both cases. I am running it on hardware with a debug build, but no debug or malloc-related breakpoints or hardfaults are being hit. As far as I can tell, the failure is in `wiced_tls_receive_packet`, line 750, on the call to : result = tls_get_next_record( context, &record, timeout, TLS_RECEIVE_PACKET_IF_NEEDED ); Unfortunately, I can't go deeper than that, since BESL in 3.1.2 is a binary. I don't quite know enough about TLS at the moment to try and do debugging around the results within `wiced_tls_receive_packet`. Any ideas as to why this is happening? |
|
相关推荐
8个回答
|
|
本质上,在TLS记录协议中,数据被划分为片段,其中每个片段可选地压缩,MAC被附加,加密,然后作为TLS记录发送。执行逆运算以接收MAC用于验证数据的数据。在您的情况下,可能由于设备中的资源限制,没有足够的内存来获取超过80KB的完整记录,并且该设备可能收到了“部分”记录。因此,MAC验证可能失败,导致无效的记录错误。检查是否释放了设备中的一些内存,减少了该问题的%发生。您可能需要OTA更改,因为该设备已经部署在该字段中。
以上来自于百度翻译 以下为原文 Essentially in the TLS record protocol, the data is divided into fragments where each fragment is optionally compressed, MAC is appended, encrypted and then transmitted as TLS record. The inverse operation is performed to receive data where the MAC is used to verify the data. In your case, it is possible that due to resource constraint in your device, there is not enough memory to fetch the complete record beyond 80kB and the device could have received a "partial" record. As a result, MAC verification could have failed resulting in the invalid record error. Check if freeing up some memory in your device reduces the % occurrence of this issue. You may need to OTA the changes since the device is already deployed in the field. |
|
|
|
asd013 发表于 2018-10-3 17:24 如果这个问题是因为缺少内存,那么它应该返回错误内存而不是ErrRo.ValueID.Read,对吗? 以上来自于百度翻译 以下为原文 If the issue is because lacking of memory, it should return ERROR_OUT_OF_MEMORY rather than ERROR_INVALID_RECORD, right? |
|
|
|
对。在上述分析的基础上,该错误应该是内存或Error SovialMac MAC的错误。但是,我们可以简单地消除内存分配问题的原因。另外,他可以做另外两个测试: 1。捕获TLS记录错误发生时的数据包并进行分析。 2。检查问题是否发生在非WICE设备或PC使用这5%个APS。这将有助于我们理解这个问题是否存在于APS或董事会中。 以上来自于百度翻译 以下为原文 Yes. Based on the above analysis, the error should have been ERROR_OUT_OF_MEMORY or ERROR_INVALID_MAC. But we could simply eliminate memory allocation as cause of the issue. Alternately he could do two other tests: 1. Capture TLS record packets when the error happens and analyse. 2. Check if the issue happens on non-WICED devices or PCs using those 5% APs. This would help us understand whether the issue lies in those APs or WICED boards. |
|
|
|
asd013 发表于 2018-10-3 17:39 WiReSARK捕获是否足以完成γ1? 以上来自于百度翻译 以下为原文 Would a WireShark capture be sufficient to accomplish #1? |
|
|
|
这将取决于通信设备。在Windows PC的情况下,WiReSkk中的WINPCAP不支持监视器模式。但是,你可以捕获TLS记录数据包到你的PC的Wi-Fi接口。但是,如果在两个不同的WICE设备之间进行通信,那么WiPCAP将无济于事,你需要NPCAP。 以上来自于百度翻译 以下为原文 It would depend on the communicating device. In case of Windows PC, winpcap in Wireshark does not support monitor mode. But you can capture TLS record packets going to and from the Wi-Fi interface of your PC. However, if the communication is between two different WICED devices, then winpcap will not help, you would need npcap. |
|
|
|
asd013 发表于 2018-10-3 18:01 GRSR 我想重新审视这个问题,因为它对我来说仍然是一个问题。 我创造了一个很小的应用程序,只使用35360 B的128KB内存。包括切换应用程序主线程静态分配(12K总),去除内部的DHCP服务器,禁用AP模式,最大1 TLS会话,并只保留STA的IP协议栈和设置其他的空指针。 不幸的是,我仍然对这个问题触及5007的结果大约82-84kbyte入流。它也总是不能在完全相同的地点,而如前所述,运行一个“调试”建立不产生任何断点陷阱而运行。 有趣的是,如果我删除内联调用wiced_framework_app_write_chunk(读取流,写入flash中,重复),然后下载成功,几乎所有的时间。有一个TTL /刷新TLS,需要通过系统的受人尊敬的速度分量?我注意到3.1.2使用max_write_size 1B为旺宏闪烁,这反过来又需要100-150ms写一张缓冲SFLASH。 以上来自于百度翻译 以下为原文 grsr I wanted to revisit this issue, since it is still a problem for me. I created a very minimal application, that only uses 35360 B of the 128KB RAM. That includes switching the application main thread to static allocation (12K in total), removing the internal DHCP server, disabling AP mode, maximum 1 TLS session, and retaining only the STA IP stack and setting the others to null pointers. Unfortunately, I am still up against this problem of hitting a 5007 result somewhere around 82-84Kbyte into the stream. It also always fails at exactly the same spot, and as mentioned before, running with a 'debug' build does not produce any breakpoint traps while running. Interestingly, if I remove the inline calls to wiced_framework_app_write_chunk (read from stream, write to flash, repeat), then the download succeeds almost all the time. Is there a TTL/refresh rate component to TLS that needs to be respected by the system? I have noticed that 3.1.2 uses a max_write_size of 1B for Macronix flashes, which in turn takes 100-150ms to write a 1024 buffer to the sflash. |
|
|
|
请叫我杰西卡 发表于 2018-10-3 18:18 我只能说在SDK3.1.2中可以达到5007的错误。 我确实见过这种错误多次。 我不确定CyPress是否仍然提供对旧BESL库的bug修复,这需要首先澄清。 以上来自于百度翻译 以下为原文 I can only say it's possible to hit 5007 error in sdk-3.1.2. I do see such error multiple times. I'm not sure if Cypress still provide bug fixes to the old BESL library, this needs to be clarified first. |
|
|
|
请叫我杰西卡 发表于 2018-10-3 18:18 安德鲁, 不幸的是,我们不支持BESL文库。如果你解决的问题解决了你的问题,你可以考虑。在没有TLS记录捕获的情况下,很难对系统的行为进行评论。 以上来自于百度翻译 以下为原文 Andrew, Unfortunately we do not support BESL library. If the workaround stated by you solves your problem, you can consider that. With no TLS record captures, it is difficult to comment on the behaviour of your system. |
|
|
|
只有小组成员才能发言,加入小组>>
716个成员聚集在这个小组
加入小组1901 浏览 1 评论
1652 浏览 1 评论
3405 浏览 1 评论
请问可以直接使用来自FX2LP固件的端点向主机FIFO写入数据吗?
1568 浏览 6 评论
1380 浏览 1 评论
CX3连接Camera修改分辨率之后,播放器无法播出camera的画面怎么解决?
188浏览 2评论
184浏览 2评论
使用stm32+cyw43438 wifi驱动whd,WHD驱动固件加载失败的原因?
322浏览 2评论
350浏览 1评论
62浏览 1评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-4-24 17:49 , Processed in 0.565584 second(s), Total 48, Slave 42 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号