obexapp-1.4

[Maksim Yevmenkin]

Pav,

>>> Well, I would expect it to print Success on the new line, not on
>>> the same line as get Soul.mp3 Soul.mp3 with 200 spaces inbetween.
>>> 
>> 
>> hmmm... that is how it works on my system. you have to hit enter
>> after 'get Soul.mp3 Soul.mp3' command, right? :) thats the newline
>> right here. so 'success etc.' should be printed on new line. are
>> you using attached console, ssh/telnet or serial console?
> 
> Actually, there is a new line when I press enter, but then the string
>  "Success..." is printed four characters before, on previous line
> four characters before the right border of terminal.
> 
> This is bash in screen in aterm.
> 
> In bash in aterm without screen it's three characters before window 
> border.
> 
> Resizing aterm does not change anything.
> 
> On real text console it prints on new line as designed.
> 
> In xterm it works as designed.
> 
> So it looks like a bad interaction of obexapp with aterm.

hmm... this does not happen in obexapp-1.3 does it? perhaps readline(3)
uses some control codes that confuse aterm?

>>>>> What about autocompletion, like in shell?
>>>> 
>>>> autocompletion for the remote filenames would be tricky to do.
>>>> directory listing is required for that. not all devices support
>>>> 'ls' command.
>>> 
>>> Perhaps it could try to do 'ls' on first 'tab' keypress, as lftp
>>> does it. I understand this would be a lot of work, probably.
>> 
>> i need to think about that. the problem is that there is no way of
>>  knowing if device supports 'ls' other then actually trying 'ls' :)
> 
> Is there any problem sending 'ls' command to unsupporting device? You
> could just try and see.

well, the thing is unsupported/unexpected command might just send device 
to a coma :) or worse. i *can* crash my nokia 6820 by just asking for 
default vcard when i'm connected to ftrn service :) my wife's se t68 
starts returning error on any command after i ask it to do something it 
cant. it just pathetic.

>>> What's interesting is that listing is printed in Unicode, but
>>> 'cd' command reacted on 'iso-8859-2' encoded name, but not on
>>> Unicode encoded name.
>> 
>> names of obex objects (obex name header) *are* in unicode. that is
>> when you type 'get foo', obexapp(1) takes 'foo' and creates obex
>> name header in request that has 'foo' translated to unicode. i
>> think your device sends back entries in the directory listing in
>> unicode and obexapp(1) have to translate it back. thats why i need
>> to see xml encoding (if any).
> 
> According to hcidump, directory listing is sent from mobile in UTF-8,
> as specified in header: <?xml version="1.0" encoding="UTF-8"?>
> 
> I can't recognize 'cd' command with my unskilled eye. Raw data are 
> attached.


< ACL data: handle 0x0029 flags 0x02 dlen 41
     L2CAP(d): cid 0x00ae len 37 [psm 3]
       RFCOMM(d): UIH: cr 1 dlci 16 pf 0 ilen 33 fcs 0x24
         OBEX: Get cmd(f): len 33
         Name (0x01) = Unicode length 2
         . .
         Type (0x42) = Sequence length 22
         x - o b e x / f o l d e r - l i s t i n
         g .
 > HCI Event: Number of Completed Packets (0x13) plen 5
   . ) . . .
 > ACL data: handle 0x0029 flags 0x02 dlen 136
     L2CAP(d): cid 0x0066 len 132 [psm 3]
       RFCOMM(d): UIH: cr 0 dlci 16 pf 1 ilen 126 fcs 0xe2 credits 1
         OBEX: Get rsp(f): status 200 len 390
         Connection ID (0xcb) = 28
         End of Body (0x49) = Sequence length 379
         < ? x m l   v e r s i o n = " 1 . 0 "
         e n c o d i n g = " U T F - 8 " ? > . .
         < ! D O C T Y P E   f o l d e r - l i s
         t i n g   S Y S T E M   " o b e x - f o
         l d e r - l i s t i n g . d t d " > . .
         < ! - - . .   X M L   C o d e
 > ACL data: handle 0x0029 flags 0x02 dlen 136
     L2CAP(d): cid 0x0066 len 132 [psm 3]
       RFCOMM(d): UIH: cr 0 dlci 16 pf 1 ilen 126 fcs 0xe2 credits 0
         OBEX: Get rsp(c): status 702 len 11296
         Session Sequence Number (0x53) = Sequence length 25965
           2 1   2 0 0 4 ,   2 2 : 5 0 : 1 0 ,
         ( C )   2 0 0 1   S o n y   E r i c s s
         o n   M o b i l e   C o m m u n i c a t
         i o n s   A B   . . - - > . . < f o l d
         e r - l i s t i n g   v e r s i o n = "
         1 . 0 " > < f o l d e r   n a m e = " O
 > ACL data: handle 0x0029 flags 0x02 dlen 136
     L2CAP(d): cid 0x0066 len 132 [psm 3]
       RFCOMM(d): UIH: cr 0 dlci 16 pf 1 ilen 126 fcs 0xe2 credits 0
         OBEX: Get rsp(c): status 602 len 29379
         Unknown (0xa1) = 122
         Unknown (0x6b) = Sequence length 31007
         / > . . < f o l d e r   n a m e = " Z v
         u k y " / > . . < f o l d e r   n a m e
         = " S c h . . m a t a " / > . . < f o l
         d e r   n a m e = " V i d e o s o u b o
         r y " / > . . < f o l d e r   n a m e =
         " J i n . . " / > . . < / f o l d e
 > ACL data: handle 0x0029 flags 0x02 dlen 22
     L2CAP(d): cid 0x0066 len 18 [psm 3]
       RFCOMM(d): UIH: cr 0 dlci 16 pf 1 ilen 12 fcs 0xe2 credits 0
         OBEX: Get rsp(c): status 702 len 11628
         Unknown (0x69) = Sequence length 29553
         i n g > . .

hmm... i'm no expert, but utf-8 is not exactly unicode. in utf-8 not all 
characters are multibytes.

and here comes 'cd' (setpath) obex command

< ACL data: handle 0x0029 flags 0x02 dlen 26
     L2CAP(d): cid 0x00ae len 22 [psm 3]
       RFCOMM(d): UIH: cr 1 dlci 16 pf 0 ilen 18 fcs 0x24
         OBEX: SetPath cmd(f): len 18 flags 2 constants 0
         Name (0x01) = Unicode length 10
         . J . i . n . . . .

notice that 'J', 'i' and 'n' encoded as 2 bytes. then there is one more 
character and null character (0x0 0x0). in utf-8 'J', 'i' and 'n' would 
have been encoded with only one byte.

so i guess obexapp(1) should use encoding header from xml and translate 
values from xml into locale one is using

max