From owner-freebsd-bluetooth@FreeBSD.ORG Fri Dec 10 23:32:13 2004 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8522216A4CE for ; Fri, 10 Dec 2004 23:32:13 +0000 (GMT) Received: from hood.oook.cz (hood.oook.cz [212.27.205.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 378FC43D45 for ; Fri, 10 Dec 2004 23:32:12 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from hood.oook.cz (localhost.oook.cz [127.0.0.1]) by hood.oook.cz (8.13.1/8.13.1) with ESMTP id iBANWBiM051833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Dec 2004 00:32:11 +0100 (CET) (envelope-from pav@FreeBSD.org) Received: (from pav@localhost) by hood.oook.cz (8.13.1/8.13.1/Submit) id iBANWA8X051832; Sat, 11 Dec 2004 00:32:10 +0100 (CET) (envelope-from pav@FreeBSD.org) X-Authentication-Warning: hood.oook.cz: pav set sender to pav@FreeBSD.org using -f From: Pav Lucistnik To: Maksim Yevmenkin In-Reply-To: <41BA2816.9000908@savvis.net> References: <41B8D6D5.6090801@savvis.net> <41B8E56C.6050409@savvis.net><41B9E211.8050005@savvis.net> <41BA2816.9000908@savvis.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WLkL5GXNomh/buy0Fkvu" Date: Sat, 11 Dec 2004 00:32:10 +0100 Message-Id: <1102721530.60420.15.camel@hood.oook.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port cc: freebsd-bluetooth@FreeBSD.org Subject: Re: obexapp-1.4 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: pav@FreeBSD.org List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 23:32:13 -0000 --=-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: > >=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 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 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--