obexapp-1.4

Pav Lucistnik pav at FreeBSD.org
Fri Dec 10 15:32:13 PST 2004


Maksim Yevmenkin píše v pá 10. 12. 2004 v 14:49 -0800:

> >>> 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?

No it does not happen in obexapp-1.3 and I don't see it in any other
readline using application, either.

> > 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.

Oh :(

> >>> 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.

Ok, so commands go in ucs or utf18 coding or something, and answers go
in coding specified in <?xml> declaration.

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

Would be very nice, yes.

-- 
Pav Lucistnik <pav at oook.cz>
              <pav at FreeBSD.org>

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: Toto je =?iso-8859-2?Q?digit=E1ln=EC?=
	=?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?=
	=?ISO-8859-1?Q?_zpr=E1vy?=
Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20041211/aeeef8c0/attachment.bin


More information about the freebsd-bluetooth mailing list