Mantis - obex-data-server
Расширенный вид
490 BIP большая всегда 2010-10-22 10:20 2010-10-27 14:13
nami  
skirsdeda  
обычный  
отработан 0.4.5  
решен  
нет    
нет  
0000490: A patch to fix bip image receive error
When client send image use ods-bip-test.py , the server will show "PARSEERR" error:

-------------------------------------------------
##DEBUG: /org/openobex/serversession3 OBEX event: PROGRESS(0x0), PUT(0x2), (null)(0x0)
io callback
OBEX_HandleInput():
obex_transport_handle_input():
obex_transport_handle_input(): Data available on client socket
obex_data_indication():
obex_transport_read(): Request to read max 32767 bytes
obex_data_indication(): Got 8 bytes
obex_data_indication(): Got 8 bytes msg len=8
obex_server():
obex_server(): STATE_REC
obex_data_request(): len = 3 bytes
obex_transport_write():
do_write(): sending 3 bytes
##DEBUG: /org/openobex/serversession3 OBEX event: PARSEERR(0x5), (null)(0x20), (null)(0x1)
obex_object_delete():
free_headerq():
free_headerq():
free_headerq():
io callback
server session closed
closing connection
OBEX_FreeInterfaces():
----------------------------------------------------------

I found that this error is caused by send_image_handle function, it should response OBEX_RSP_CONTINUE but not OBEX_RSP_SUCCESS. So I make a patch to fix this bug.

--- /home/nami/obex-data-server-0.4.5/src/ods-server-session.c 2009-10-21 22:10:19.000000000 +0800
+++ ./ods-server-session.c 2010-10-22 15:22:20.741507926 +0800
@@ -298,7 +298,7 @@
         if (server_session->priv->require_imaging_thumbnails)
             OBEX_ObjectSetRsp (object, OBEX_RSP_PARTIAL_CONTENT, OBEX_RSP_PARTIAL_CONTENT);
         else
- OBEX_ObjectSetRsp (object, OBEX_RSP_SUCCESS, OBEX_RSP_SUCCESS);
+ OBEX_ObjectSetRsp (object, OBEX_RSP_CONTINUE, OBEX_RSP_SUCCESS);
     }
 }

I verified it ,the server can receive image correctly.
? file icon rsp_success [^] (212,525 bytes) 2010-10-25 14:26
? file icon rsp_continue [^] (4,450,140 bytes) 2010-10-25 14:28
история
2010-10-22 10:20 nami Новый вопрос
2010-10-25 08:34 skirsdeda Комментарий добавлен: 0001388
2010-10-25 08:44 skirsdeda Состояние новый => назначен
2010-10-25 08:44 skirsdeda Ответственный => skirsdeda
2010-10-25 12:12 skirsdeda Комментарий добавлен: 0001390
2010-10-25 12:36 nami Комментарий добавлен: 0001391
2010-10-25 12:46 skirsdeda Комментарий добавлен: 0001392
2010-10-25 14:25 nami Комментарий добавлен: 0001393
2010-10-25 14:26 nami Файл добавлен: rsp_success
2010-10-25 14:28 nami Файл добавлен: rsp_continue
2010-10-25 15:38 skirsdeda Комментарий добавлен: 0001394
2010-10-27 14:13 skirsdeda Комментарий добавлен: 0001395
2010-10-27 14:13 skirsdeda Состояние назначен => отработан
2010-10-27 14:13 skirsdeda Решение открыт => решен

Комментарии
(0001388)
skirsdeda   
2010-10-25 08:34   
Thanks for the bug report. I'll commit it to svn ASAP.
(0001390)
skirsdeda   
2010-10-25 12:12   
I had a closer look at this and it seems that your fix might only be working for very small files (see comment in the beginning of send_image_handle() function). According to specification, response code after receiving "image put" should be success, partial response or any error code, so your fix might be handling a corner case. If you could verify my suspicions by testing with a bigger file, I would appreciate it.
(0001391)
nami   
2010-10-25 12:36   
I tested with file about 2.8M,is it big enough? Current ods contains Body header in image put request, so I think the server should response continue.
(0001392)
skirsdeda   
2010-10-25 12:46   
It seems I have misinterpreted this :) Could you post a hcidump output for your test case with you bug-fix just to be 100% sure?
(0001393)
nami   
2010-10-25 14:25   
I checked again. The image file is 2.8M.
 If the server responses success, the ods-bip-test.py shows that the transfer is 100% completed, but if you look the server receive image file, you can find that the image is only 31.8KB. This is becaused server received success response, so it thinked the transfer is over and will not expect client next frame. When client next put frame was comming,the server got PARSEERR error.The hcidump log is attached as rsp_success file.
If the server responses continue ,when the file is transfered over, the server received image file is truely 2.8M.The corsponding hcidump log is atached as rsp_continue file.
(0001394)
skirsdeda   
2010-10-25 15:38   
ok, thanks a lot :) You're right. Sorry for disturbing you :)
(0001395)
skirsdeda   
2010-10-27 14:13   
fixed in svn trunk