obexapp 1.4.5

dear bluetooth users,

please give a try to new obexapp 1.4.5

http://www.geocities.com/m_evmenkin/obexapp-1.4.5.tar.gz


in this release

- obex mtu fixes (submitted by Alexander V. Ribchansky)

- obexapp now registers both opush and ftrn services

- obexapp now supports quotation (with backslash ) in file
names
(with spaces etc.)

- other minor fixes

please let me know if you have any problems

thanks,
max
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

dear bluetooth users,

please give a try to new obexapp 1.4.5

http://www.geocities.com/m_evmenkin/obexapp-1.4.5.tar.gz


in this release

- obex mtu fixes (submitted by Alexander V. Ribchansky)

- obexapp now registers both opush and ftrn services

- obexapp now supports quotation (with backslash ) in file
names
(with spaces etc.)

- other minor fixes

please let me know if you have any problems

thanks,
max
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

On Tue, 30 Jan 2007, Maksim Yevmenkin wrote:

> please let me know if you have any problems

Not problems exactly; obexapp works fine on NetBSD with
minimal changes
(is available from pkgsrc/comms/obexapp)

It would be good if the manpage could mention that for
server mode, it
might be necessary to also set the "Object
Transfer" bit (0x100000) in the
class of device.  eg, my Nokia 6103 filters out devices that
do not have
that bit set during discovery..

I do not really understand the -f option, client mode does
not seem to
work without it when sending files to my phone..

iain

_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

On Tue, 20 Feb 2007, Iain Hibbert wrote:

> On Tue, 30 Jan 2007, Maksim Yevmenkin wrote:
>
> > please let me know if you have any problems
>
> Not problems exactly; obexapp works fine on NetBSD with
minimal changes
> (is available from pkgsrc/comms/obexapp)

One problem that I have found, is that the "-u"
option does not work
properly - well, the setgid()/setuid() does work but the
OBEX_ServerRegister() fails because the process no longer
has privilege to
register services..

I had to change the privilege checking part of sdpd(8) for
NetBSD since we
do not have the LOCAL_PEERCRED message and I wonder if this
is related to
that..  I guess the following works fine in FreeBSD?

	# obexapp -s -S -C 10 -u user

iain
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

Iain,

> It would be good if the manpage could mention that for
server mode, it
> might be necessary to also set the "Object
Transfer" bit (0x100000) in the
> class of device.  eg, my Nokia 6103 filters out devices
that do not have
> that bit set during discovery..

ok, i will add this to the man page.

> I do not really understand the -f option, client mode
does not seem to
> work without it when sending files to my phone..

-f means connect to "file browsing service".
basically it will make
obexapp to put additional header into connect request.
obexapp can be
used to do both obex push and obex file transfer. if both
services are
running on the same rfcomm port then extra header in the
connect
request can be used to identify which service client is
requesting. it
somewhat similar to the host: header in http.

so, if you are connecting to obex file transfer service, -f
option is
required (assuming that obex server was properly
implemented)

thanks,
max
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

Iain,

> One problem that I have found, is that the
"-u" option does not work
> properly - well, the setgid()/setuid() does work but
the
> OBEX_ServerRegister() fails because the process no
longer has privilege to
> register services..

well, the sdp_session_open() is called before
setgid()/setuid() so
sdpd will mark this session as "privileged". once
sdp session is open,
obexapp can drop its privileges and still be able to
register service
with sdpd.

> I had to change the privilege checking part of sdpd(8)
for NetBSD since we
> do not have the LOCAL_PEERCRED message and I wonder if
this is related to
> that..  I guess the following works fine in FreeBSD?
>
>         # obexapp -s -S -C 10 -u user

yes, it works just fine.

i guess, for the sake of compatibility, i could change
libsdp/sdpd to
something similar to LOCAL_CREDS (or whatever supported by
BSDs),
where local sdp client is expected to send its credentials
right after
the session is opened. this would require minor change to
libsdp's
sdp_open_local and sdpd(8).

thanks,
max
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

On Wed, 21 Feb 2007, Maksim Yevmenkin wrote:
> well, the sdp_session_open() is called before
setgid()/setuid() so
> sdpd will mark this session as "privileged".
once sdp session is open,
> obexapp can drop its privileges and still be able to
register service
> with sdpd.

I think the problem with my implementation of this is that
the SCM_CREDS
information is sent alongside the first normal message, and
because that
are not sent until after the setuid(), the credentials have
changed..

As I recall, for PEER_CREDS, sdpd actively queries the
remote credentials
when as the socket is open - (it seems that a slight race
condition could
exist there, or are the credentials passed the ones that
were used to open
the socket?)

I will look into this a bit more, maybe if I arrange to
send() an zero
length message before changing the uid it may work, though
I'm not sure
how well sdpd will handle that..

iain
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

On Wed, 21 Feb 2007, Maksim Yevmenkin wrote:

> so, if you are connecting to obex file transfer
service, -f option is
> required (assuming that obex server was properly
implemented)

Ah yes, thanks..

% obexapp -a phone -C opush -n put 21.jpg

does indeed work..

iain
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

On 2/21/07, Iain Hibbert <plunkyrya-online.net> wrote:
> On Wed, 21 Feb 2007, Maksim Yevmenkin wrote:
> > well, the sdp_session_open() is called before
setgid()/setuid() so
> > sdpd will mark this session as
"privileged". once sdp session is open,
> > obexapp can drop its privileges and still be able
to register service
> > with sdpd.
>
> I think the problem with my implementation of this is
that the SCM_CREDS
> information is sent alongside the first normal message,
and because that
> are not sent until after the setuid(), the credentials
have changed..

ok

> As I recall, for PEER_CREDS, sdpd actively queries the
remote credentials
> when as the socket is open - (it seems that a slight
race condition could
> exist there, or are the credentials passed the ones
that were used to open
> the socket?)

i do not think so, from kern/uipc_usrreq.c

...
                /*
                 * unp_peercred management:
                 *
                 * The connecter's (client's) credentials
are copied from its
                 * process structure at the time of
connect() (which is now).
                 */
                cru2x(td->td_ucred,
&unp3->unp_peercred);
                unp3->unp_flags |= UNP_HAVEPC;
                /*
                 * The receiver's (server's) credentials are
copied from the
                 * unp_peercred member of socket on which
the former called
                 * listen(); unp_listen() cached that
process's credentials
                 * at that time so we can use them now.
                 */
...

> I will look into this a bit more, maybe if I arrange to
send() an zero
> length message before changing the uid it may work,
though I'm not sure
> how well sdpd will handle that..

i'm not sure what are you suggesting

thanks,
max
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"