Date: Sat, 04 Dec 2004 11:04:29 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Tuc at Beach House <tuc@tucs-beachin-obx-house.com> Cc: freebsd-bluetooth@freebsd.org Subject: Re: sdpcontrol issues (LONG) Message-ID: <41B20A3D.4030008@savvis.net> In-Reply-To: <200412041706.iB4H6ME2013457@himinbjorg.tucs-beachin-obx-house.com> References: <200412041706.iB4H6ME2013457@himinbjorg.tucs-beachin-obx-house.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello,
> FreeBSD himinbjorg.tucs-beachin-obx-house.com 5.2.1-RELEASE FreeBSD
> 5.2.1-RELEASE #7: Tue Oct 12 15:07:09 EDT 2004
> root@himinbjorg.tucs-beachin-obx-house.com:/usr/obj/usr/src/sys/HIMINBJORG
> i386
bluetooth in 5.2.1 is not very user frilendly. please upgrade your
system to 5.3 or 5-stable.
[snip - all output looks good to me]
> So I went on to hccontrol -n ubt0hci read_connection_list , which
> came up empty. I'm not sure that this should really show anything.
it will if you have open baseband connection. please note that stack
will shutdown inactive baseband connections after few seconds of inactivity.
> So I skipped down to the l2ping -a
> TucTreo650.tucs-beachin-obx-house.com and all of a sudden on the Treo
> I get some tones and it tells me a connection is in progress. The
> results of the ping are :
>
> 20 bytes from 00:07:e0:02:16:16 seq_no=0 time=2081.812 ms result=0 20
> bytes from 00:07:e0:02:16:16 seq_no=1 time=31.914 ms result=0 20
> bytes from 00:07:e0:02:16:16 seq_no=2 time=45.864 ms result=0 20
> bytes from 00:07:e0:02:16:16 seq_no=3 time=27.612 ms result=0 20
> bytes from 00:07:e0:02:16:16 seq_no=4 time=30.311 ms result=0 20
> bytes from 00:07:e0:02:16:16 seq_no=5 time=33.280 ms result=0
>
> (The treo had timed out so the first one I had to turn it back on.)
> Just for giggles, I went back to the hccontrol -n ubt0hci
> read_connection_list and saw :
>
> Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State
> TucTreo650.tucs-b 41 ACL 0 MAST NONE 0 0 OPEN
>
> So it looks pretty good.
yep, that is exactly what it should look like. l2ping will open baseband
connection for you. if you stop l2ping and wait few seconds then
baseband connection will be terminated due to inactivity.
> I try the l2control -a himinbjorg.tucs-beachin-obx-house.com
> read_channel_list (I already put my BD_ADDR in the
> /etc/bluetooth/hosts as : 00:11:95:00:39:15
> himinbjorg.tucs-beachin-obx-house.com )
>
> And it comes up empty. So does the read_connection_list, unless I do
> the l2ping and quickly go back. Then I get :
>
> L2CAP connections: Remote BD_ADDR Handle Flags Pending State
> TucTreo650.tucs-b 42 O D 0 OPEN
that is fine to. read_connection_list command in both l2control and
hcicontrol should have similar output. if they do then everything is
fine - hci and l2cap have consistent information. if they dont then
something is bad.
> I go on to a btsockstat, and get :
>
> Active raw HCI sockets Socket PCB Flags Recv-Q Send-Q Local
> address c891c960 c7f01280 000002 0 0 *
thats fine too. you do not have yet open any _logical_ connections on
top of baseband connections, i.e. you do not have l2cap or rfcomm
channels open.
> So now I skip down to section 24.4.6 .
>
> My first question is how should I be starting hcsecd on a regular
> basis? I don't see anything in the /etc/rc.bluetooth to do it. So in
> the /etc/bluetooth/hcsecd.conf I put :
>
> device { bdaddr 00:07:e0:02:16:16; name "palmOne Device"; key
> nokey; pin "1234"; }
>
> and after realizing the default file has some sort of error on line
> 44, I have to comment it out :
>
> #device { # bdaddr 00:1:2:3:4:5; # name "Dummy"; #
> key nokey; # pin "0000"; #}
>
> I run it, and tell the Palm to trust my laptop. The debug is :
>
> hcsecd[12989]: Got PIN_Code_Request event from 'ubt0hci', remote
> bdaddr 00:07:e0:02:16:16 hcsecd[12989]: Found matching entry, remote
> bdaddr 00:07:e0:02:16:16, name 'palmOne Device', PIN code exists
> hcsecd[12989]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr
> 00:07:e0:02:16:16 hcsecd[12989]: Got Link_Key_Notification event from
> 'ubt0hci', remote bdaddr 00:07:e0:02:16:16
yes, thats looks good to me. i will verify the default (example) section
in /etc/bluetooth/hcsecd.conf.
> I move on to the next section, and this is where things start to go
> bad.
>
> I do a sdpcontrol -a TucTreo650.tucs-beachin-obx-house.com browse and
> I get:
>
> Could not execute command "browse". Input/output error
>
> I did a search of all the options, each come up as Input/output
> error.
well, i will double check, but i think thats because of endianess bug in
sdpcontrol. it was fixed later.
> I then try to start sdpd, and it doesn't exist.
sdpd was not included in 5.2.1. you _do_not_ need to run sdpd unless you
want to provide bluetooth services to remote clients, i.e. act as a server
> I drop down to sdpcontrol -l browse and I get it as an illegal
> option.
'-l' option appeared later when sdpd was added. it means browse _local_
sdpd database. again you _do_not_ need this unless host provides
bluetoth services.
i'd strongly recommend to upgrade the system to 5.3 or 5-stable. you
could so source upgreade (cvsup/buildworld) if you have time.
thanks,
max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41B20A3D.4030008>