From owner-freebsd-bluetooth@FreeBSD.ORG Fri Dec 10 22:50:15 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 DFD3716A4CE; Fri, 10 Dec 2004 22:50:15 +0000 (GMT) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B1DA43D39; Fri, 10 Dec 2004 22:50:15 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from out001.email.savvis.net (out001.apptix.savvis.net [216.91.32.44])iBAMoCZb025795; Fri, 10 Dec 2004 16:50:12 -0600 Received: from s228130hz1ew17.apptix-01.savvis.net ([10.146.4.29]) by out001.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Dec 2004 16:50:09 -0600 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew17.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Dec 2004 16:49:59 -0600 Message-ID: <41BA2816.9000908@savvis.net> Date: Fri, 10 Dec 2004 14:49:58 -0800 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pav@FreeBSD.org References: <41B8D6D5.6090801@savvis.net> <1102634931.90683.9.camel@hood.oook.cz> <41B8E56C.6050409@savvis.net> <1102668370.34937.7.camel@pav.hide.vol.cz> <41B9E211.8050005@savvis.net> <1102709951.60420.9.camel@hood.oook.cz> In-Reply-To: <1102709951.60420.9.camel@hood.oook.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Dec 2004 22:49:59.0904 (UTC) FILETIME=[9401F600:01C4DF0A] X-ECS-MailScanner: No virus is found cc: freebsd-bluetooth@FreeBSD.org Subject: Re: obexapp-1.4 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list 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 22:50:16 -0000 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: > > 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