Date: Fri, 10 Dec 2004 09:51:13 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: pav@FreeBSD.org Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: obexapp-1.4 Message-ID: <41B9E211.8050005@savvis.net> In-Reply-To: <1102668370.34937.7.camel@pav.hide.vol.cz> References: <41B8D6D5.6090801@savvis.net> <1102634931.90683.9.camel@hood.oook.cz> <41B8E56C.6050409@savvis.net> <1102668370.34937.7.camel@pav.hide.vol.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Pav, >>>obex> get Soul.mp3 Soul.mp3 >>>Success, response: OK, Success (0x20) >>> >>>obex> get Wazzup.mp3 >>>Failure, response: Unautorized (0x41) >>> >>>When I write get with single argument, could obexapp assume it as both >>>remote and local filename? >> >>well, it could. right now i opted for non-intuitive version :) that is >>'get foo' means get default vcard object and save it locally as foo :) >>funky, huh? :) >> >>i do not like it myself, and i'm not sure how often one wants to pull >>default vcard object. i like your idea better, i.e. 'get foo' should >>mean 'get foo foo'. perhaps adding another command to get default object >>would be better? > > Exactly. I see you already implemented this, I will test 1.4.1 in the > evening (I have my bluetooth dongle at home). yep, thats done 1.4.1 >> > There's some odity with line breaks, it seems, on my terminal: >> >>>+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >>>| obex> get Soul.mp3 Soul.mp3 Success, response: OK, Success (0x20) | >>>| obex> get Wazzup.mp3 >>>| Failure, response: Unautorized (0x41) >>>+------------------------------------- >>> >>>Should there be so many spaces and shouldn't there be line break before >>>"Success" ? >> >>i'm not really sure what do you mean. could you please provide a sample >>of what you would like output to be? > > 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? >>>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' :) >>>What about unicode characters? My cell phones have czech localisation >>>and name of directories visible over OBEX are with czech characters, >>>coded in Unicode. Accessible for me with obexapp but in latin2 charset: >>> >>>obex> ls >>>Access Owner Group Size Modified Name >>> n/a n/a n/a n/a Obrázky/ >>> n/a n/a n/a n/a Zvuky/ >>> n/a n/a n/a n/a Schémata/ >>> n/a n/a n/a n/a Videosoubory/ >>> n/a n/a n/a n/a Jiné/ >>>Success, response: OK, Success (0x20) >>>obex> cd Jiné >>>Failure, response: Not found (0x44) >>>obex> cd Jiné >>>Success, response: OK, Success (0x20) >> >>well, directory listing is a xml document. i just get it and parse/print >>it with bsdxml(3). does your phone sets xml charset? (hint: use hcidump >>to actually see xml :) > >>unicode input is a completely different beast. you actually have to >>switch your console to unicode. > > 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). > I will check with hcidump in the evening. > >>>It wanted to pair my cell phone on connect, obexapp-1.3 does not wanted >>>to pair. >> >>obexapp does not care about piring. if you want to authenticate incoming >>connection on freebsd you have to use hccontrol(8). right now there is >>no way to turn authentication on individual connections. its all or none. > > It's more about that phone suddenly wanted to pair with my computer. > With obexapp-1.3, it just allowed computer to connect, but did not > allowed to browse any directories, only to upload files into root. > With obexapp-1.4, it want to pair, otherwise it drop the connection, but > now it allows browsing subdirectories and getting files from/to them. > > I'm not sure if I dislike the new way, I'm just reporting difference. hmmm.... that's weird. *nothing* in obexapp(1) could have caused this. one thing you can try is to get rid of your phone key in '/var/db/hcsecd.keys' file, restart hcsecd(8) and then re-pair. also there is a difference between 'opush' and 'ftrn'. opush will only let you work with 'inbox', that is no ls, cd etc. ftrn will let you do all these things, but you might need to specify '-f' switch to obexapp(1) - connect to file browsing service. i'm still somewhat confused about 'file browsing sevice (-f switch)' and when one must use it :( thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41B9E211.8050005>