All of lore.kernel.org
 help / color / mirror / Atom feed
* [Bluez-users] RecHandle
@ 2007-04-10 10:30 gerhard.ramsebner
  2007-04-10 14:22 ` Marcel Holtmann
  0 siblings, 1 reply; 5+ messages in thread
From: gerhard.ramsebner @ 2007-04-10 10:30 UTC (permalink / raw)
  To: Bluez-users

I'm writing start/stop scripts for bluetooth services.
Assuming I want to run several servises of the same type and stop them
later on. How can I make a difference between the related sdpd records
easily? Unfotunately  'sdptool add' does not provide the RecHandle.

Surprisingly RecHandles differ with the command issued. Is there any
special reason for that behaviour?

# sdptool search --bdaddr local SP
[...]
Service RecHandle: 0x10001
[...]

# sdptool get SP
[...]
Service RecHandle: 0x0
[...]


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-users] RecHandle
  2007-04-10 10:30 [Bluez-users] RecHandle gerhard.ramsebner
@ 2007-04-10 14:22 ` Marcel Holtmann
  2007-04-10 19:31   ` gerhard.ramsebner
  0 siblings, 1 reply; 5+ messages in thread
From: Marcel Holtmann @ 2007-04-10 14:22 UTC (permalink / raw)
  To: BlueZ users

Hi Gerhard,

> I'm writing start/stop scripts for bluetooth services.
> Assuming I want to run several servises of the same type and stop them
> later on. How can I make a difference between the related sdpd records
> easily? Unfotunately  'sdptool add' does not provide the RecHandle.

don't even do it this way. The services should register the records by
themself and all of the ones included in bluez-utils do so.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-users] RecHandle
  2007-04-10 14:22 ` Marcel Holtmann
@ 2007-04-10 19:31   ` gerhard.ramsebner
  2007-04-10 19:34     ` Marcel Holtmann
  0 siblings, 1 reply; 5+ messages in thread
From: gerhard.ramsebner @ 2007-04-10 19:31 UTC (permalink / raw)
  To: BlueZ users

Hi Marcel,

>> I'm writing start/stop scripts for bluetooth services.
>> Assuming I want to run several servises of the same type and stop them
>> later on. How can I make a difference between the related sdpd records
>> easily? Unfotunately  'sdptool add' does not provide the RecHandle.
>
> don't even do it this way. The services should register the records by
> themself and all of the ones included in bluez-utils do so.
>

Well, rfcomm does not. Or is there something wrong with mine?


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-users] RecHandle
  2007-04-10 19:31   ` gerhard.ramsebner
@ 2007-04-10 19:34     ` Marcel Holtmann
  2007-04-10 20:43       ` gerhard.ramsebner
  0 siblings, 1 reply; 5+ messages in thread
From: Marcel Holtmann @ 2007-04-10 19:34 UTC (permalink / raw)
  To: BlueZ users

Hi Gerhard,

> >> I'm writing start/stop scripts for bluetooth services.
> >> Assuming I want to run several servises of the same type and stop them
> >> later on. How can I make a difference between the related sdpd records
> >> easily? Unfotunately  'sdptool add' does not provide the RecHandle.
> >
> > don't even do it this way. The services should register the records by
> > themself and all of the ones included in bluez-utils do so.
> >
> 
> Well, rfcomm does not. Or is there something wrong with mine?

that is true, but RFCOMM is also not a service implementation. However
feel free to send in patches if you think it is useful.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-users] RecHandle
  2007-04-10 19:34     ` Marcel Holtmann
@ 2007-04-10 20:43       ` gerhard.ramsebner
  0 siblings, 0 replies; 5+ messages in thread
From: gerhard.ramsebner @ 2007-04-10 20:43 UTC (permalink / raw)
  To: BlueZ users

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

Hi Marcel,

my idea was to have an embedded device automatically connecting to a host
system providing rfcomm. This embedded device might go down from time to
time but should normaly be streaming sensor data. To keep things easy I
thougt it would be advantageous to avoid implementing an ip streaming in
favour of rfcomm.
Thatfor on hostside I wrote a script to have 'rfcomm listen' restarted
everytime it goes down due to hangup. The embedded device should
{,re}connect to it whenever it starts up.

This is working quite well with a single connection. I'm not planning to
have more than one but the script would be more elegante if this were
possible.
But this also does mean that I have to offer to stop a channel without
closing one of the others.

You don't think that this is a good idea, do you?
Respect to all taking part!

Regards,
gerhard


2 files attached:
rc_rfcomm - bash start/stopscript (replace the function 'boot_mesg',
'evaluate_retval' and 'echo_warning' with something appropriate or get
their definitions here:
http://www.linuxfromscratch.org/blfs/downloads/6.2.0/blfs-bootscripts-20060910.tar.bz2)
rfcomm_listen - bash daemon script called from rc_rfcomm.

[-- Attachment #2: rfcomm_listen --]
[-- Type: application/octet-stream, Size: 571 bytes --]

#!/bin/bash

PIDFILE=$(basename ${0})
PIDFILE=${PIDFILE%.*}
PIDFILE=/var/run/${PIDFILE}.pid

if [ -e ${PIDFILE} ]
then
	printf "*** %s : pidfile exists\n" ${0} >&2
	exit 1
else
	touch ${PIDFILE} && echo $$ > ${PIDFILE}
	if [ ! -e ${PIDFILE} ]
	then
		printf "*** %s : failed to create pidfile\n" ${0} >&2
		exit 1
	fi
fi

SCHEDULE='kill ${!}; rm -f ${PIDFILE}; exit'
trap "${SCHEDULE}" 3
trap "${SCHEDULE}" 6
trap "${SCHEDULE}" 9
trap "${SCHEDULE}" 15

while true
do
	nice -n 10 rfcomm listen 1>/dev/null 2>/dev/null ${*} &
	wait ${!}
	# prevent DoS attack
	sleep 1
done

[-- Attachment #3: rc_rfcomm --]
[-- Type: application/octet-stream, Size: 1248 bytes --]

#!/bin/sh

. /etc/sysconfig/rc
. $rc_functions

case "$1" in
	start)
		boot_mesg "Starting rfcomm..."
		nice -n 10 rfcomm_listen -A --channel=1 hci0 &
		# rfcomm_listen takes time to create pidfile
		sleep 1
		# rfcomm_listen exits if pidfile exists
		if [ ${!} -eq $(cat /var/run/rfcomm_listen.pid) ]
		then
			disown ${!} && sdptool add --channel=1 SP
		else
			/bin/false
		fi
		evaluate_retval
		;;

	stop)
		boot_mesg "Stopping rfcomm..."
		WARN=0
		if [ -e /var/run/rfcomm_listen.pid ]
		then
			kill $(cat /var/run/rfcomm_listen.pid)
			# rfcomm_listen takes time to remove pidfiled
			sleep 1
		else
			echo "pidfile does not exist"
			WARN=1
		fi
		if [ -e /var/run/rfcomm_listen.pid ]
		then
			echo "pidfile still exists"
			WARN=1
		fi
		RecHandles=$(sdptool search --bdaddr local SP \
			| grep 'Service RecHandle' \
			| sed 's/^Service RecHandle: //')
		for RecHandle in ${RecHandles}
		do
			sdptool del ${RecHandle}
		done
		if [ ${WARN} -gt 0 ]
		then
			echo_warning
			exit
		fi
		/bin/true
		evaluate_retval
		;;

	restart)
		$0 stop
		sleep 1
		$0 start
		;;

	status)
		statusproc rfcomm_listen
		rfcomm -a
		echo
		sdptool search --bdaddr local SP
		;;

	*)
		echo "Usage: $0 {start|stop|restart|status}"
		exit 1
		;;
esac

[-- Attachment #4: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #5: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2007-04-10 20:43 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-04-10 10:30 [Bluez-users] RecHandle gerhard.ramsebner
2007-04-10 14:22 ` Marcel Holtmann
2007-04-10 19:31   ` gerhard.ramsebner
2007-04-10 19:34     ` Marcel Holtmann
2007-04-10 20:43       ` gerhard.ramsebner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.