Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000490 [obex-data-server] BIP major always 2010-10-22 10:20 2010-10-27 14:13
Reporter nami View Status public  
Assigned To skirsdeda
Priority normal Resolution fixed  
Status resolved   Product Version 0.4.5
Summary 0000490: A patch to fix bip image receive error
Description 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.
Additional Information
Tags No tags attached.
Attached Files ? 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

- Relationships

-  Notes
(0001388)
skirsdeda (administrator)
2010-10-25 08:34

Thanks for the bug report. I'll commit it to svn ASAP.
(0001390)
skirsdeda (administrator)
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 (reporter)
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 (administrator)
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 (reporter)
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 (administrator)
2010-10-25 15:38

ok, thanks a lot :) You're right. Sorry for disturbing you :)
(0001395)
skirsdeda (administrator)
2010-10-27 14:13

fixed in svn trunk

- Issue History
Date Modified Username Field Change
2010-10-22 10:20 nami New Issue
2010-10-25 08:34 skirsdeda Note Added: 0001388
2010-10-25 08:44 skirsdeda Status new => assigned
2010-10-25 08:44 skirsdeda Assigned To => skirsdeda
2010-10-25 12:12 skirsdeda Note Added: 0001390
2010-10-25 12:36 nami Note Added: 0001391
2010-10-25 12:46 skirsdeda Note Added: 0001392
2010-10-25 14:25 nami Note Added: 0001393
2010-10-25 14:26 nami File Added: rsp_success
2010-10-25 14:28 nami File Added: rsp_continue
2010-10-25 15:38 skirsdeda Note Added: 0001394
2010-10-27 14:13 skirsdeda Note Added: 0001395
2010-10-27 14:13 skirsdeda Status assigned => resolved
2010-10-27 14:13 skirsdeda Resolution open => fixed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker