通过卷曲抛出MPFSIMG2.BIN文件

好的，这是我找到的。通过浏览器/MPFSUPPLAD页面上传文件创建两个TCP包。一个是标题（帖子、密码等）和/r/n/r/n空字符串。第二个是2974个字节，更多的报头（缓存控制和内容类型，然后是另一个/r/n/r/n和MPFS/ 01／02签名）。文件上传过程TCPIPPHTTPYMPFSUPPLAUD（）（在http.c）查找第二个“/r/n/r/n”，如果没有发现它丢弃当前TCP包并等待另一个包：这在WiReSARK中是什么样子：到目前为止是如此好。但是如果我们使用CURL，则它发送数据在三个TCP包中，316, 210个和7354个字节，其中MPFS签名位于FILD包的开始（见图）。因此，TCPIPPHTTPYMPFSUPPLAUDE（）无法找到任何“/r/N/R/N MPFS／01／02”字符串，最终无法达到这个奇怪的TLB异常。现在，我通过检查“/R/N/R/N MPFS／01／02”，而不是“MPFS/01／02”字符串来修复这个问题，尽管我不确定这是否是100%正确的。感谢您的意见。修补代码：
                    
                    
               
                                                                                      以下为原文

                                                                            OK, here is what I found. Uploading file via browser's /mpfsupload page creates two TCP packets. One is with headers (POST, password etc) and /r/n/r/n empty string. Second is 2974 bytes, more headers (cache-control and content type, then another /r/n/r/n and MPFS/01/02 signature). File upload procedure TCPIP_HTTP_MPFSUpload() (in http.c) looks for second "/r/n/r/n", and if didn't find it discards current TCP packet and waits for another one:
 
case HTTP_MPFS_UP:
pHttpCon->uploadSectNo = 0;
lenA = TCPIP_TCP_ArrayFind(pHttpCon->socket, (const uint8_t*)"rnrn", 4, 0, 0, false); //here we check for rnrn
  if(lenA != 0xffff) {// Found it, so remove all data up to and including //skipped some code
if(memcmp(nvmBuffer, (const void*)MPFS_SIGNATURE, sizeof(MPFS_SIGNATURE)-1) == 0) //here we check for MPFS signature 
Here how this looks like in Wireshark:

 
So far so good. But if we are using CURL, it sends data in three TCP packets, 316, 210, and 7354 bytes, in which MPFS signature located in very beginning of fird packet (see picture). Therefore, TCPIP_HTTP_MPFSUpload() can't find any "/r/n/r/n MPFS/01/02" string, and eventually failing to this odd TLB exception. 
 

 
For now, I fixed this by checking not "/r/n/r/n MPFS/01/02", but "MPFS/01/02" string, though I'm not sure if this is 100% correct.  Comments are appreciated.
 
Patched code:

case HTTP_MPFS_UP:
pHttpCon->uploadSectNo = 0;
lenA = TCPIP_TCP_ArrayFind(pHttpCon->socket, (const uint8_t*)MPFS_SIGNATURE, sizeof(MPFS_SIGNATURE)-1, 0, 0, false);if(lenA != 0xffff)
{// Found it, so remove all data up to and including
lenA = TCPIP_TCP_ArrayGet(pHttpCon->socket, NULL, lenA + sizeof(MPFS_SIGNATURE)-1);
pHttpCon->byteCount -= (lenA + sizeof(MPFS_SIGNATURE)-1);
if(1)
{ // Read as Ver 2.1
// allocate the buffer size as a multiple of sector size
mpfsAllocSize = ((MPFS_UPLOAD_WRITE_BUFFER_SIZE + (SYS_FS_MEDIA_SECTOR_SIZE - 1)) / SYS_FS_MEDIA_SECTOR_SIZE) * SYS_FS_MEDIA_SECTOR_SIZE;

我会仔细研究并提供一个解决方案。同时请使用你的解决方案。不管怎样，堆栈不应该崩溃，RN是否存在。它应该在那里。当我有东西的时候我会更新。谢谢你的报道。
                    
                    
               
                                                                                      以下为原文

                                                                            I'll be looking into this and provide a resolution ASAP.
Meanwhile please use your workaround.
No matter what, the stack should not crash, rn present or not. It should be there though.
I'll update when I have something.
Thank you for reporting this.