Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Dec 2004 21:19:11 +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:  <1102709951.60420.9.camel@hood.oook.cz>
In-Reply-To: <41B9E211.8050005@savvis.net>
References:  <41B8D6D5.6090801@savvis.net> <41B8E56C.6050409@savvis.net><41B9E211.8050005@savvis.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--=-5V1iNfHAGBFV/QZ1QFAu
Content-Type: multipart/mixed; boundary="=-9Zhm/FJNOtuOdSJ5M61Q"


--=-9Zhm/FJNOtuOdSJ5M61Q
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

Maksim Yevmenkin p=ED=A8e v p=E1 10. 12. 2004 v 09:51 -0800:

> >>  > There's some odity with line breaks, it seems, on my terminal:
> >>
> >>>+---------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
--------------+
> >>>| obex> get Soul.mp3 Soul.mp3                                         =
                                                                           =
                                                   Success, response: OK, S=
uccess (0x20) |
> >>>| obex> get Wazzup.mp3
> >>>| Failure, response: Unautorized (0x41)
> >>>+-------------------------------------
> >>>
> >>>Should there be so many spaces and shouldn't there be line break befor=
e
> >>>"Success" ?
> >>
> >>i'm not really sure what do you mean. could you please provide a sample=
=20
> >>of what you would like output to be?
> >=20
> > 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
> hmmm... that is how it works on my system. you have to hit enter after=20
> 'get Soul.mp3 Soul.mp3' command, right? :) thats the newline right here.=20
> so 'success etc.' should be printed on new line. are you using attached=20
> 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.

> >>>What about autocompletion, like in shell?
> >>
> >>autocompletion for the remote filenames would be tricky to do. director=
y=20
> >>listing is required for that. not all devices support 'ls' command.
> >=20
> > 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.
>=20
> i need to think about that. the problem is that there is no way of=20
> 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.

> >>>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=C3=A1zky/
> >>>          n/a      n/a      n/a        n/a              Zvuky/
> >>>          n/a      n/a      n/a        n/a              Sch=C3=A9mata/
> >>>          n/a      n/a      n/a        n/a              Videosoubory/
> >>>          n/a      n/a      n/a        n/a              Jin=C3=A9/
> >>>Success, response: OK, Success (0x20)
> >>>obex> cd Jin=C3=A9
> >>>Failure, response: Not found (0x44)
> >>>obex> cd Jin=E9
> >>>Success, response: OK, Success (0x20)
> >>
> >>well, directory listing is a xml document. i just get it and parse/prin=
t=20
> >>it with bsdxml(3). does your phone sets xml charset? (hint: use hcidump=
=20
> >>to actually see xml :)
> >=20
> >>unicode input is a completely different beast. you actually have to=20
> >>switch your console to unicode.
> >=20
> > What's interesting is that listing is printed in Unicode, but 'cd'
> > command reacted on 'iso-8859-2' encoded name, but not on Unicode encode=
d
> > name.
>=20
> names of obex objects (obex name header) *are* in unicode. that is when=20
> you type 'get foo', obexapp(1) takes 'foo' and creates obex name header=20
> in request that has 'foo' translated to unicode. i think your device=20
> sends back entries in the directory listing in unicode and obexapp(1)=20
> 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=3D"1.0" encoding=3D"UTF-8"?>

I can't recognize 'cd' command with my unskilled eye. Raw data are
attached.

> > I will check with hcidump in the evening.
> >=20
> >>>It wanted to pair my cell phone on connect, obexapp-1.3 does not wante=
d
> >>>to pair.
> >>
> >>obexapp does not care about piring. if you want to authenticate incomin=
g=20
> >>connection on freebsd you have to use hccontrol(8). right now there is=20
> >>no way to turn authentication on individual connections. its all or non=
e.
> >=20
> > 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, bu=
t
> > now it allows browsing subdirectories and getting files from/to them.
> >=20
> > I'm not sure if I dislike the new way, I'm just reporting difference.
>=20
> hmmm.... that's weird. *nothing* in obexapp(1) could have caused this.=20
> one thing you can try is to get rid of your phone key in=20
> '/var/db/hcsecd.keys' file, restart hcsecd(8) and then re-pair. also=20
> there is a difference between 'opush' and 'ftrn'. opush will only let=20
> you work with 'inbox', that is no ls, cd etc. ftrn will let you do all=20
> these things, but you might need to specify '-f' switch to obexapp(1) -=20
> connect to file browsing service. i'm still somewhat confused about=20
> 'file browsing sevice (-f switch)' and when one must use it :(

I goofed here. It depends on RFCOMM channel I use, if I use OPUSH it
works without pairing, if I use IRMC it want to pair. obexapp-1.3
behaves exactly same, I verified. Sorry for confusion.

--=20
Pav Lucistnik <pav@oook.cz>
              <pav@FreeBSD.org>

Define universe and tell me three examples.

--=-9Zhm/FJNOtuOdSJ5M61Q--

--=-5V1iNfHAGBFV/QZ1QFAu
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)

iD8DBQBBugS/ntdYP8FOsoIRAkrHAKCPuDJ1zxzXtHuXO61rq+m7W0+58QCgrrb+
VvWl94sa39SepGnwPObctTE=
=YhxF
-----END PGP SIGNATURE-----

--=-5V1iNfHAGBFV/QZ1QFAu--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1102709951.60420.9.camel>