Date: Sat, 11 Dec 2004 00:32:10 +0100 From: Pav Lucistnik <pav@FreeBSD.org> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: obexapp-1.4 Message-ID: <1102721530.60420.15.camel@hood.oook.cz> In-Reply-To: <41BA2816.9000908@savvis.net> References: <41B8D6D5.6090801@savvis.net> <41B8E56C.6050409@savvis.net><41B9E211.8050005@savvis.net> <41BA2816.9000908@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-WLkL5GXNomh/buy0Fkvu
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Maksim Yevmenkin p=ED=B9e v p=E1 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.
> >>>=20
> >>=20
> >> 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?
> >=20
> > 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.
> >=20
> > This is bash in screen in aterm.
> >=20
> > In bash in aterm without screen it's three characters before window=20
> > border.
> >=20
> > Resizing aterm does not change anything.
> >=20
> > On real text console it prints on new line as designed.
> >=20
> > In xterm it works as designed.
> >=20
> > So it looks like a bad interaction of obexapp with aterm.
>=20
> 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.
>=20
> well, the thing is unsupported/unexpected command might just send device=20
> to a coma :) or worse. i *can* crash my nokia 6820 by just asking for=20
> default vcard when i'm connected to ftrn service :) my wife's se t68=20
> starts returning error on any command after i ask it to do something it=20
> 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.
> >>=20
> >> 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).
> >=20
> > According to hcidump, directory listing is sent from mobile in UTF-8,
> > as specified in header: <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> >=20
> > I can't recognize 'cd' command with my unskilled eye. Raw data are=20
> > attached.
>=20
>=20
> < 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) =3D Unicode length 2
> . .
> Type (0x42) =3D 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) =3D 28
> End of Body (0x49) =3D Sequence length 379
> < ? x m l v e r s i o n =3D " 1 . 0 "
> e n c o d i n g =3D " 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) =3D 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 =3D "
> 1 . 0 " > < f o l d e r n a m e =3D " 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) =3D 122
> Unknown (0x6b) =3D Sequence length 31007
> / > . . < f o l d e r n a m e =3D " Z v
> u k y " / > . . < f o l d e r n a m e
> =3D " S c h . . m a t a " / > . . < f o l
> d e r n a m e =3D " V i d e o s o u b o
> r y " / > . . < f o l d e r n a m e =3D
> " 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) =3D Sequence length 29553
> i n g > . .
>=20
> hmm... i'm no expert, but utf-8 is not exactly unicode. in utf-8 not all=20
> characters are multibytes.
>=20
> and here comes 'cd' (setpath) obex command
>=20
> < 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) =3D Unicode length 10
> . J . i . n . . . .
>=20
> notice that 'J', 'i' and 'n' encoded as 2 bytes. then there is one more=20
> character and null character (0x0 0x0). in utf-8 'J', 'i' and 'n' would=20
> 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=20
> values from xml into locale one is using
Would be very nice, yes.
--=20
Pav Lucistnik <pav@oook.cz>
<pav@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.
--=-WLkL5GXNomh/buy0Fkvu
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: 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?=
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)
iD8DBQBBujH6ntdYP8FOsoIRArv8AKC22R+bp/kbko71NmEU1KPK0mOeFACfRpqE
WhrFsXkxXBrvkvoFqerz+Ak=
=rp+x
-----END PGP SIGNATURE-----
--=-WLkL5GXNomh/buy0Fkvu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1102721530.60420.15.camel>