From: Marcel Holtmann <marcel@holtmann.org>
To: Hendrik Sattler <post@hendrik-sattler.de>
Cc: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] SDP services cannot be unregistered
Date: Thu, 20 Dec 2007 03:09:39 +0100 [thread overview]
Message-ID: <1198116580.8050.232.camel@aeonflux> (raw)
In-Reply-To: <200712200229.40589.post@hendrik-sattler.de>
Hi Hendrik,
> > > since several versions of bluez userspace libs and utils, I am unable to
> > > unregister local SDP server records. Everything I tried so far fails to
> > > unregister the record:
> > > I use sdp_connect() and sdp_device_record_register() to register the SDP
> > > record and use the return result of the latter for
> > > sdp_device_record_unregister() and then sdp_close().
> > >
> > > In earlier versions, the unregistering and explicit closing of the
> > > session handle wasn't even necessary but that broke. That can be handled
> > > but unregistering a record in an explicit way like above should work,
> > > doesn't it?
> > >
> > > When the bug appeared, I though that waiting some versions might suffice.
> > > But obviously, nobody ever noticed.
> > > Is there a possibility that this gets fixed?
> >
> > not sure about that. Never heard about it. Are you using the sdpd daemon
> > or do you use hcid -s and the embedded SDP server?
> >
> > I might have introduced a bug when switching everything over to the
> > embedded SDP server and the automatic service classes handling. Do you
> > have a simple reproducer that I can try?
>
> Yes, current obexpushd from my repository at
> https://www.hendrik-sattler.de/svn/obexpushd/trunk/
>
> I see this since about 3.11 when that entered Debian testing, current is 3.22.
> I assume that the embedded SDP server might be the cause, at least Debian
> uses it. BTW: kdebluetooth has the same problem.
> I also reported that as Debian bug report
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445677
first of all you are using the unregister function wrongly. You have to
give it the exact record structure you gave the register function. So
when you allocate a new record, then the unregister has no idea what to
do with it.
Why it doesn't cleanup after program termination is unclear to me. That
should actually work. You might wanna investigate on that one.
Regards
Marcel
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2007-12-20 2:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-19 22:41 [Bluez-devel] SDP services cannot be unregistered Hendrik Sattler
2007-12-19 23:34 ` Marcel Holtmann
[not found] ` <200712200229.40589.post@hendrik-sattler.de>
2007-12-20 2:09 ` Marcel Holtmann [this message]
2007-12-20 9:20 ` Hendrik Sattler
2007-12-20 15:08 ` Marcel Holtmann
2007-12-20 21:40 ` Hendrik Sattler
2007-12-20 23:12 ` Marcel Holtmann
2007-12-20 9:59 ` [Bluez-devel] Multi-device : maximizing the number of concurrent ourgoing RFCOMM connections Olivier Le Pogam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1198116580.8050.232.camel@aeonflux \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
--cc=post@hendrik-sattler.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox