Mantis Bugtracker
главная | моя сводка | список вопросов | журнал изменений | план развития | документация | моя учетная запись
  

Простой вид [ комментарии ] [ расширенный вид ] [ история ] [ печать ]
Номер Категория Серьезность Воспроизводимость Создан Изменен
0000490 [obex-data-server] 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.
Дополнительные сведения
Tэги Нет прикрепленных тэгов.
Вложенные файлы ? 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

- Связи

-  Комментарии
(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

- история
Дата изменения Пользователь Поле Изменение
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 Решение открыт => решен

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