Problem with setPath

[GoogleCodeExporter]

Hi!
I'm having a problem with setPath request: either it blocks in read
operation, or returns "Bad request" response code. This happens when I'm
trying to connect using Bluecove OBEX implementation from PC to WM6, PC to
Nokia phone, PC to Samsung Phone, WM6 to PC, Nokia to PC etc... The same 
Java code (which makes connect and setpath on a remote device) works fine
when I'm using Nokia native OBEX implementation. Here's the code basically:

           ClientSession connection = (ClientSession)
Connector.open(serviceUrl);
           HeaderSet header = connection.createHeaderSet();
           byte[] FBUiid =
{(byte)0xF9,(byte)0xEC,(byte)0x7B,(byte)0xC4,(byte)0x95,(byte)0x3C,(byte)0x11,(b
yte)0xD2,

(byte)0x98,(byte)0x4E,(byte)0x52,(byte)0x54,(byte)0x00,(byte)0xDC,(byte)0x9E,(by
te)0x09};
           header.setHeader(HeaderSet.TARGET, FBUiid);
           HeaderSet response = connection.connect(header);
           header = connection.createHeaderSet();
           header.setHeader(HeaderSet.NAME, "");
           header = connection.setPath(header, false, false);

Anticipating the response that the issue was fixed in SNAPSHOT 2.0.3 :),
I'd like to ask you for updated bluecove.dll, because I can't build it
('cause I don't have Platform SDK, and no intentions to download it, 'cause
it's huge...). If you could just send me the 2.0.3 bluecove.dll on
denis.kubasov@gmail.com, I'd appreciate! 

Thanks!

Original issue reported on code.google.com by Denis.Ku...@gmail.com on 28 Jun 2008 at 10:18

[GoogleCodeExporter]

I've found dll, so I can run now the latest version. And as I can see, my 
problem
still persists...

Sorry, I did not give any details in the previous post. On my PC (WinXP) and 
pocket
pc (WM6) it is WIDCOMM stack, and I'm using bluecove for a client application 
which
connects to the default OBEX FTP service, provided by the BT stack. Initially 
the
idea was to write such application for my Nokia 6500, but I've encountered some 
bugs
or incoherences in Nokia native OBEX implementation, so I thought of using your 
OBEX
implementation (over the native Nokia RFCOMM) instead. 

The problem with Nokia OBEX is it throws an exception "Invalid ISO8601 time 
stamp"
when parsing received headers after issuing "get file" request to WIDCOMM OBEX
servers. Other operations (including folder listing, set path) as well as "get 
file"
requests to Samsung z500v phone worked fine.

With bluecove I have different problems... From a Windows device (WinXP or WM6) 
I'm
able to connect to all my devices (connect() returns OBEX_HTTP_OK), but:
1. setPath() doesn't work at all - either freezes until timeout, or returns 192 
("Bad
request") response code;
2. get() works only when connecting to Nokia; with other devices it freezes, or
sometimes returns code 144 (??).

May be I miss something important? It is strange that no one reported earlier 
about
problems with setPath... Thank you in advance for any help!

Original comment by Denis.Ku...@gmail.com on 28 Jun 2008 at 11:59

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Here comes an update :)

1. Issue with freezing "get" is solved by adding final bit to the opcode:
(OBEXOperationCodes.GET | OBEXOperationCodes.FINAL_BIT) instead of just
OBEXOperationCodes.GET;

2. setPath freezes between two WIDCOMMs (client on PC accessing server on WM6),
otherwise (client still on PC, server on Nokia and Samsung) returns 192. 
Freezing is
very similar to the first case, when server was waiting for final bit:
readOperation() is locked during the first readFully() call, that means that the
stream is totally empty, server did not write data to it (?). But setPath adds 
final
bit, so I don't understand what is the problem here...

Original comment by Denis.Ku...@gmail.com on 28 Jun 2008 at 5:20

[GoogleCodeExporter]

Please use different Issue for different problems!!
Was the problem (Issue #40) with date resolved? Reply in appropriate 
thread/Issue 

Please keep in mind that I'm unable to understand the problem with setPath and 
how
you solved it or how I can reproduce it. You may report bugs in Russian if it is
simpler for you.

When "it freezes" please make thread dump to clarify the problem.

Also Are you sure this bluecove problem and not the problem with obex on 
another device?

Original comment by skarzhev...@gmail.com on 1 Jul 2008 at 12:11

[GoogleCodeExporter]

Sorry for confusing you, but this issue with "Invalid ISO8601 time stamp" is
different from issue#40 - it is Nokia problem apparently and has nothing to do 
with
bluecove (I mentioned it just to explain why I need bluecove).

I understand that you don't bother reading carefully large bug reports, and I 
respect
your time and efforts. That's why I describe the problem here again in simple 
words
that you can understand: setPath doesn't work! At least in my configuration, 
which I
described above: OBEX FTP client, calling setPath, is running on PC with WinXP 
or
PocketPC with WM6 (both have with WIDCOMM stack); FTP server is Nokia 6500, 
Samsung
z500v, WinXP or WM6. My guess is that the SETPATH request issued by bluecove is
somehow incomplete, and server waits for some more headers/packets before 
responding. 

How do I make a thread dump?

I'm not in anything concerning bluetooth and obex, because I've encountered a 
lot of
different behaviours; seems like no one follows the specification. Of course 
there's
a possibility that bluecove works fine, and OBEX FTP servers on my two phones 
and two
windows-powered devices have bugs... However, they all (except Nokia) respond
properly to setPath requests issued from the Nokia phone (using it's native OBEX
implementation).

Is it understandable this time? I can translate it into russian or french if 
you want.

Original comment by Denis.Ku...@gmail.com on 1 Jul 2008 at 8:37

[GoogleCodeExporter]

And please consider adding final bit to the GET operation code
(OBEXOperationCodes.GET | OBEXOperationCodes.FINAL_BIT) because it solved one 
problem
for me... 

Original comment by Denis.Ku...@gmail.com on 1 Jul 2008 at 8:42

[GoogleCodeExporter]

In short the OBEX code I made is not 100% confirm to the JSR and may have a 
problems.
It is sill in development. See module bluecove-tests, some tests are failing. 
Also
some TCK tests are falling when connecting to WTK. But they are not related to 
your
problems.

The problem with FINAL_BIT.
According to spec you can sent multiple headers. Only when finished sending 
headers
the final bit is sent.  In your case the Operation openInputStream() from client
should sent the final bit to the server....
  So as I see obex can send GET and then GET | FINAL_BIT bit... 
  This is how I understood the specification documents!

  If I can see the code you are using to connect to FTP server.

  I had tested setPath() only using TCK and WTK obex over TCP.

  Also the proper test should be done using open obex ftp server on Linux or Windows
if available. I think WIDCOMM ftp also may confirm to the standards but I never
tested it.

  If you interested in helping me find the differences in ftp set path created by
Nokia and BlueCove. This can be done creating simple ftp server using bluecove 
and
running it in debug mode so bluecove will print all packets and headers 
received from
the client. I don't have obex ftp client on my nokia phone so I can't help. But 
may
be open obex or other tools can be used.

 To solve the problems with "different behaviors" we can introduce some extra
configuration options in bluecove as temporary solutions.....

 Anyway to fix the obex is one of my top priority outstanding Issue in BlueCove. But
unfortunately it require much more time than I have right now. And as it stand 
right
now all other members in the project are unable to help. We need new blood in 
the
project.
 Recently I changed the code dramatically to accept the InputStream in Operation Get
and OutputStream in Put for sending binary headers.

 Please continue out discussions in
http://groups.google.com/group/bluecove-developers I'll send you the invitation.

Original comment by skarzhev...@gmail.com on 1 Jul 2008 at 3:47

• Changed state: Accepted

[GoogleCodeExporter]

Fixed to the best of my knowledge.
- setPath() and flags order corrected
- Client operations will try to use short Request Phase and send just 'final' 
packet
 when applicable.

Original comment by skarzhev...@gmail.com on 4 Jul 2008 at 4:34

• Changed state: Fixed-SNAPSHOT
• Added labels: OpSys-All

[GoogleCodeExporter]

Thank you Vlad, it works now! :)

Original comment by Denis.Ku...@gmail.com on 4 Jul 2008 at 9:55

[GoogleCodeExporter]

Original comment by skarzhev...@gmail.com on 5 Sep 2008 at 7:16

• Changed state: Fixed