From ml at os2.kiev.ua  Sat Nov  1 13:30:00 2008
From: ml at os2.kiev.ua (Alex Samorukov)
Date: Sat Nov  1 13:30:06 2008
Subject: bt dev questions
In-Reply-To: <bb4a86c70810311030xcd59409wd1d630a1061d456a@mail.gmail.com>
References: <490B331F.6020305@os2.kiev.ua>
	<bb4a86c70810311030xcd59409wd1d630a1061d456a@mail.gmail.com>
Message-ID: <490CB692.6040303@os2.kiev.ua>

Maksim Yevmenkin wrote:
>
>>  1) Why sdpd require root permission to open session? As for me it`s enough
>> to check use file permissions on control socket. In Linux its possible to
>> register service w/o root permissions, so in ported version I need to run it
>> as root and then setuid to normal user.  What is the reason for this?
>>     
>
> to have better control over what services are offered. basically, i do
> not want to have any random application go and register bunch of
> non-existent services. requiring 'root' permission is may be a little
> bit excessive, but its easy to fix. could teach sdpd to accept
> connections from specified group (or even list of groups/users).
>
>   
Yes, i think that its enough to have group, with sdpd r/w permission. 
Because I don`t like setgid/setuid, and this will allow to avoid this in 
bt services.
>>  2) I was not able to find how to change provider name and server
>> description in SDP_SERVICE_CLASS_SERIAL_PORT profile. anyRemote using usual
>> serial over bluetooth, but with changed service name field. I found howto
>> change channel (server_channel) but not description. Is it possible at all?
>>     
>
> not at this time.
>
>   
ok, np )
>>  I`m planning to submit my patches to the ports tree at nearest time.
>>     
>
> thanks for your work.
>   
Thank you too. Author answered that he will include my patches to the 
next version, so soon anyRemote will work in freebsd out of the box.

From mad at madpilot.net  Tue Nov  4 03:19:49 2008
From: mad at madpilot.net (Guido Falsi)
Date: Tue Nov  4 03:19:56 2008
Subject: RFComm behaviour with nokia mobiles
Message-ID: <20081104111947.GB62907@megatron.madpilot.net>

Hello,

While working on the gnokii port I noticed a strange behaviour with
recent 7.1-prerelease in respect to rfcomm_sppd.

I'm quite sure I'm doing something wronjg...something stupid, but
I can't figure what.

I have 2 Nokia phones, one 6021 and one 6233.

I completed the gnokii adaption to talk to freebsd sdp and it tries
to connwect to rf channel 15 on both phnes, the same rfcomm_sppd
tries. It loooks like the correct one in fact, but even after
associating the phone with hcsecd I can't really connect.

rfcomm_sppd looks like it's connected, phone seems to accept the
connection but stays stuck with a "trying to connect to <pc name>"
message on display.  If I try to send anything through rfcomm_sppd
connection is lost(phone reports failed).

I'm not sure what is wrong, I will try with an old sonyericcson
phone as soon as I can, but just to know, it's some well known nokia
strangeness or have I messed up somewhere?

I have some memory of tI have some memory of this working with one
of these phones in the past(and sending at commands to it), but I'm
not sure if I'm getting confused with some olde

Thank you in advance.

-- 
Guido Falsi <mad@madpilot.net>
From plunky at rya-online.net  Tue Nov  4 03:46:17 2008
From: plunky at rya-online.net (Iain Hibbert)
Date: Tue Nov  4 03:46:24 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <20081104111947.GB62907@megatron.madpilot.net>
References: <20081104111947.GB62907@megatron.madpilot.net>
Message-ID: <1225799105.807983.1164.nullmailer@galant.ukfsn.org>

On Tue, 4 Nov 2008, Guido Falsi wrote:

> I completed the gnokii adaption to talk to freebsd sdp and it tries
> to connwect to rf channel 15 on both phnes, the same rfcomm_sppd
> tries. It loooks like the correct one in fact, but even after
> associating the phone with hcsecd I can't really connect.

can you show what the output of sdpcontrol is when examining this service?

(try search for protocol 0x0003 should give all RFCOMM channels)

IIRC if you are connecting to a serial port service then it is not always
the case that there will be an AT command interpreter at the other end..

also, the patch below adds support to print out the primary language
ServiceName to the port of sdpcontrol I made for NetBSD. It might not
apply cleanly to original sdpcontrol but should not be too difficult to
adapt and it seems quite useful..

I haven't committed it here because its not really complete as the string
that is produced is not guaranteed to be ASCII (the spec recommends using
UTF-8) but I would have to examine the languagebase settings and do some
iconv magic to get it 100% correct.

iain

--- /usr/src/usr.bin/sdpquery/search.c	2007-11-09 20:10:29.000000000 +0000
+++ search.c	2008-11-01 17:26:52.000000000 +0000
@@ -83,7 +83,9 @@ static uint32_t	attrs[] =
 	SDP_ATTR_RANGE(	SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST,
 			SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST),
 	SDP_ATTR_RANGE(	SDP_ATTR_BLUETOOTH_PROFILE_DESCRIPTOR_LIST,
-			SDP_ATTR_BLUETOOTH_PROFILE_DESCRIPTOR_LIST)
+			SDP_ATTR_BLUETOOTH_PROFILE_DESCRIPTOR_LIST),
+	SDP_ATTR_RANGE(	SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID + SDP_ATTR_SERVICE_NAME_OFFSET,
+			SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID + SDP_ATTR_SERVICE_NAME_OFFSET),
 };
 #define attrs_len	(sizeof(attrs)/sizeof(attrs[0]))

@@ -524,6 +526,47 @@ print_bluetooth_profile_descriptor_list(
 	}
 } /* print_bluetooth_profile_descriptor_list */

+static void
+print_service_name(uint8_t const *start, uint8_t const *end)
+{
+	uint32_t	type, len;
+
+	if (end - start < 2) {
+		fprintf(stderr, "Invalid Service Name. " \
+				"Too short, len=%zd\n", end - start);
+		return;
+	}
+
+	SDP_GET8(type, start);
+	switch (type) {
+	case SDP_DATA_STR8:
+		SDP_GET8(len, start);
+		break;
+
+	case SDP_DATA_STR16:
+		SDP_GET16(len, start);
+		break;
+
+	case SDP_DATA_STR32:
+		SDP_GET32(len, start);
+		break;
+
+	default:
+		fprintf(stderr, "Invalid Service Name. " \
+				"Not a string, type=%#x\n", type);
+		return;
+		/* NOT REACHED */
+	}
+
+	if (start + len > end) {
+		fprintf(stderr, "Invalid Service Name. " \
+				"Too short, len=%d (%zd)\n", len, end - start);
+		return;
+	}
+
+	fprintf(stdout, "\t\"%*.*s\"\n", len, len, start);
+} /* print_service_name */
+
 struct service {
 	const char	*name;
 	uint16_t	class;
@@ -651,6 +694,12 @@ do_sdp_search(bdaddr_t *laddr, bdaddr_t
 					values[n].value + values[n].vlen);
 			break;

+		case SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID + SDP_ATTR_SERVICE_NAME_OFFSET:
+			fprintf(stdout, "Service Name:\n");
+			print_service_name(values[n].value,
+					values[n].value + values[n].vlen);
+			break;
+
 		default:
 			fprintf(stderr, "Unexpected attribute ID=%#4.4x\n",
 					values[n].attr);
From mad at madpilot.net  Tue Nov  4 05:51:08 2008
From: mad at madpilot.net (Guido Falsi)
Date: Tue Nov  4 05:51:26 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <1225799105.807983.1164.nullmailer@galant.ukfsn.org>
References: <20081104111947.GB62907@megatron.madpilot.net>
	<1225799105.807983.1164.nullmailer@galant.ukfsn.org>
Message-ID: <20081104135107.GA64776@megatron.madpilot.net>

On Tue, Nov 04, 2008 at 11:45:05AM +0000, Iain Hibbert wrote:
> On Tue, 4 Nov 2008, Guido Falsi wrote:
> 
> > I completed the gnokii adaption to talk to freebsd sdp and it tries
> > to connwect to rf channel 15 on both phnes, the same rfcomm_sppd
> > tries. It loooks like the correct one in fact, but even after
> > associating the phone with hcsecd I can't really connect.
> 
> can you show what the output of sdpcontrol is when examining this service?
> 
> (try search for protocol 0x0003 should give all RFCOMM channels)

I'm attaching the output from the 6233.

The problem is not finding the channel, but that the only channel which
looks correct is not acting the way it should(ie. accept at commands...)

> 
> IIRC if you are connecting to a serial port service then it is not always
> the case that there will be an AT command interpreter at the other end..

Sure, but I thought it standard to have at least una port accepting at
commands. Also because it's the only standard interface to talk to
mobiles from PCs (Nokia PC suite and other proprietary software not
being standard IMHO).

> 
> also, the patch below adds support to print out the primary language
> ServiceName to the port of sdpcontrol I made for NetBSD. It might not
> apply cleanly to original sdpcontrol but should not be too difficult to
> adapt and it seems quite useful..
> 
> I haven't committed it here because its not really complete as the string
> that is produced is not guaranteed to be ASCII (the spec recommends using
> UTF-8) but I would have to examine the languagebase settings and do some
> iconv magic to get it 100% correct.

I've written something simlar to adapt the gnokii sdp functions. The
channel choosen is 15 because it looks like an rfcomm modem like
port.Perhaps these phones don't have such a port. I'll try with my older
sony-ericsson, which I know for sure used to accept at commands via
bluetooth.

-- 
Guido Falsi <mad@madpilot.net>
-------------- next part --------------

Record Handle: 0x00010000
Service Class ID List:
	Dial-Up Networking (0x1103)
	Generic Networking (0x1201)
Protocol Descriptor List:
	L2CAP (0x0100)
	RFCOMM (0x0003)
		Protocol specific parameter #1: u/int8/bool 1
Bluetooth Profile Descriptor List:
	Dial-Up Networking (0x1103) ver. 1.0

Record Handle: 0x00010001
Service Class ID List:
	Serial Port (0x1101)
Protocol Descriptor List:
	L2CAP (0x0100)
	RFCOMM (0x0003)
		Protocol specific parameter #1: u/int8/bool 15

Record Handle: 0x00010002
Service Class ID List:
	Serial Port (0x1101)
Protocol Descriptor List:
	L2CAP (0x0100)
	RFCOMM (0x0003)
		Protocol specific parameter #1: u/int8/bool 3

Record Handle: 0x00010003
Service Class ID List:
	Handsfree Audio Gateway (0x111f)
	Generic Audio (0x1203)
Protocol Descriptor List:
	L2CAP (0x0100)
	RFCOMM (0x0003)
		Protocol specific parameter #1: u/int8/bool 13
Bluetooth Profile Descriptor List:
	Handsfree (0x111e) ver. 1.5

Record Handle: 0x00010004
Service Class ID List:
	Headset Audio Gateway (0x1112)
	Generic Audio (0x1203)
Protocol Descriptor List:
	L2CAP (0x0100)
	RFCOMM (0x0003)
		Protocol specific parameter #1: u/int8/bool 12
Bluetooth Profile Descriptor List:
	Headset (0x1108) ver. 1.0

Record Handle: 0x0001000b
Service Class ID List:
	OBEX Object Push (0x1105)
Protocol Descriptor List:
	L2CAP (0x0100)
	RFCOMM (0x0003)
		Protocol specific parameter #1: u/int8/bool 9
	OBEX (0x0008)
Bluetooth Profile Descriptor List:
	OBEX Object Push (0x1105) ver. 1.0

Record Handle: 0x0001000c
Service Class ID List:
	OBEX File Transfer (0x1106)
Protocol Descriptor List:
	L2CAP (0x0100)
	RFCOMM (0x0003)
		Protocol specific parameter #1: u/int8/bool 10
	OBEX (0x0008)
Bluetooth Profile Descriptor List:
	OBEX File Transfer (0x1106) ver. 1.0

Record Handle: 0x0001000e
Service Class ID List:
	0x00000002-0000-1000-8000-0002ee000002
Protocol Descriptor List:
	L2CAP (0x0100)
	RFCOMM (0x0003)
		Protocol specific parameter #1: u/int8/bool 11
	OBEX (0x0008)

Record Handle: 0x0001000f
Service Class ID List:
	SIM Access (0x112d)
	Generic Telephony (0x1204)
Protocol Descriptor List:
	L2CAP (0x0100)
	RFCOMM (0x0003)
		Protocol specific parameter #1: u/int8/bool 4
Bluetooth Profile Descriptor List:
	SIM Access (0x112d) ver. 1.1
From plunky at rya-online.net  Tue Nov  4 10:06:09 2008
From: plunky at rya-online.net (Iain Hibbert)
Date: Tue Nov  4 10:06:19 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <20081104135107.GA64776@megatron.madpilot.net>
References: <20081104111947.GB62907@megatron.madpilot.net>
	<1225799105.807983.1164.nullmailer@galant.ukfsn.org>
	<20081104135107.GA64776@megatron.madpilot.net>
Message-ID: <1225821264.107584.759.nullmailer@galant.ukfsn.org>

On Tue, 4 Nov 2008, Guido Falsi wrote:

> On Tue, Nov 04, 2008 at 11:45:05AM +0000, Iain Hibbert wrote:
> > On Tue, 4 Nov 2008, Guido Falsi wrote:
> >
> > > I completed the gnokii adaption to talk to freebsd sdp and it tries
> > > to connwect to rf channel 15 on both phnes, the same rfcomm_sppd
> > > tries. It loooks like the correct one in fact, but even after
> > > associating the phone with hcsecd I can't really connect.
> >
> > can you show what the output of sdpcontrol is when examining this service?
> >
> > (try search for protocol 0x0003 should give all RFCOMM channels)
>
> I'm attaching the output from the 6233.
>
> The problem is not finding the channel, but that the only channel which
> looks correct is not acting the way it should(ie. accept at commands...)

btw my 6103 also has similar ports on similar channels:

Record Handle: 0x00010000
Service Class ID List:
	Dial-Up Networking (0x1103)
	Generic Networking (0x1201)
Protocol Descriptor List:
	L2CAP (0x0100)
	RFCOMM (0x0003)
		Protocol specific parameter #1: u/int8/bool 1
Bluetooth Profile Descriptor List:
	Dial-Up Networking (0x1103) ver. 1.0
Service Name:
	"Dial-up networking"

Record Handle: 0x00010001
Service Class ID List:
	Serial Port (0x1101)
Protocol Descriptor List:
	L2CAP (0x0100)
	RFCOMM (0x0003)
		Protocol specific parameter #1: u/int8/bool 15
Service Name:
	"Nokia PC Suite"

Record Handle: 0x00010002
Service Class ID List:
	Serial Port (0x1101)
Protocol Descriptor List:
	L2CAP (0x0100)
	RFCOMM (0x0003)
		Protocol specific parameter #1: u/int8/bool 3
Service Name:
	"COM 1"

and I see that connecting to DUN gives me an AT command interpreter as
does SP on 3 (COM 1) but connecting to the SP on 15 (Nokia PC Suite)
doesn't. Thats using NetBSD though the program is not much different.

can you connect to channel 1 (Dialup Networking) with rfcomm_sppd?  That
should definitely take AT commands..

btw, didn't you say before that gnokii is supposed to be discarding "Nokia
PC Suite" ?  (actually, that was why I added the "Service Name" handling,
so I could see what my phone had :)

iain
From maksim.yevmenkin at gmail.com  Tue Nov  4 10:17:03 2008
From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin)
Date: Tue Nov  4 10:17:09 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <1225821264.107584.759.nullmailer@galant.ukfsn.org>
References: <20081104111947.GB62907@megatron.madpilot.net>
	<1225799105.807983.1164.nullmailer@galant.ukfsn.org>
	<20081104135107.GA64776@megatron.madpilot.net>
	<1225821264.107584.759.nullmailer@galant.ukfsn.org>
Message-ID: <bb4a86c70811041017g7b6822fej492caa56157fada3@mail.gmail.com>

On 11/4/08, Iain Hibbert <plunky@rya-online.net> wrote:
> On Tue, 4 Nov 2008, Guido Falsi wrote:
>
>  > On Tue, Nov 04, 2008 at 11:45:05AM +0000, Iain Hibbert wrote:
>  > > On Tue, 4 Nov 2008, Guido Falsi wrote:
>  > >
>  > > > I completed the gnokii adaption to talk to freebsd sdp and it tries
>  > > > to connwect to rf channel 15 on both phnes, the same rfcomm_sppd
>  > > > tries. It loooks like the correct one in fact, but even after
>  > > > associating the phone with hcsecd I can't really connect.
>  > >
>  > > can you show what the output of sdpcontrol is when examining this service?
>  > >
>  > > (try search for protocol 0x0003 should give all RFCOMM channels)
>  >
>  > I'm attaching the output from the 6233.
>  >
>  > The problem is not finding the channel, but that the only channel which
>  > looks correct is not acting the way it should(ie. accept at commands...)
>
>
> btw my 6103 also has similar ports on similar channels:
>
>  Record Handle: 0x00010000
>  Service Class ID List:
>         Dial-Up Networking (0x1103)
>         Generic Networking (0x1201)
>  Protocol Descriptor List:
>         L2CAP (0x0100)
>         RFCOMM (0x0003)
>                 Protocol specific parameter #1: u/int8/bool 1
>  Bluetooth Profile Descriptor List:
>         Dial-Up Networking (0x1103) ver. 1.0
>  Service Name:
>         "Dial-up networking"
>
>  Record Handle: 0x00010001
>  Service Class ID List:
>         Serial Port (0x1101)
>  Protocol Descriptor List:
>         L2CAP (0x0100)
>         RFCOMM (0x0003)
>                 Protocol specific parameter #1: u/int8/bool 15
>  Service Name:
>         "Nokia PC Suite"
>
>  Record Handle: 0x00010002
>  Service Class ID List:
>         Serial Port (0x1101)
>  Protocol Descriptor List:
>         L2CAP (0x0100)
>         RFCOMM (0x0003)
>                 Protocol specific parameter #1: u/int8/bool 3
>  Service Name:
>         "COM 1"
>
>  and I see that connecting to DUN gives me an AT command interpreter as
>  does SP on 3 (COM 1) but connecting to the SP on 15 (Nokia PC Suite)
>  doesn't. Thats using NetBSD though the program is not much different.
>
>  can you connect to channel 1 (Dialup Networking) with rfcomm_sppd?  That
>  should definitely take AT commands..
>
>  btw, didn't you say before that gnokii is supposed to be discarding "Nokia
>  PC Suite" ?  (actually, that was why I added the "Service Name" handling,
>  so I could see what my phone had :)

could you please run hcidump and see what is going on after you
connect to the "pc suite" service. some (most/simbian-based?)  nokia
phones have some sort of the callback mechanism, i.e. pc suite
connects to the phone service and then immediately disconnects. this
somehow tells the phone to initiate connection back to the pc on
serial port service. rfcomm_pppd(8) man page has a little notes on
that.

Iain is right, using dun service is the best bet to get "modem" serial port.

thanks,
max
From plunky at rya-online.net  Tue Nov  4 11:17:53 2008
From: plunky at rya-online.net (Iain Hibbert)
Date: Tue Nov  4 11:17:59 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <bb4a86c70811041017g7b6822fej492caa56157fada3@mail.gmail.com>
References: <20081104111947.GB62907@megatron.madpilot.net> 
	<1225799105.807983.1164.nullmailer@galant.ukfsn.org> 
	<20081104135107.GA64776@megatron.madpilot.net>
	<1225821264.107584.759.nullmailer@galant.ukfsn.org>
	<bb4a86c70811041017g7b6822fej492caa56157fada3@mail.gmail.com>
Message-ID: <1225826167.716196.1082.nullmailer@galant.ukfsn.org>

On Tue, 4 Nov 2008, Maksim Yevmenkin wrote:

> could you please run hcidump and see what is going on after you
> connect to the "pc suite" service. some (most/simbian-based?)  nokia
> phones have some sort of the callback mechanism, i.e. pc suite
> connects to the phone service and then immediately disconnects. this
> somehow tells the phone to initiate connection back to the pc on
> serial port service. rfcomm_pppd(8) man page has a little notes on
> that.

It doesn't seem to do that here (dump attached), though its not a symbian
phone. The phone enables encryption and accepts the RFCOMM connection to
channel 15 (dlci 30), then sends some credits and waits. If I send any
data (in this case, pressed return 0x0d) then it disconnects.  I left it a
short while but it didn't try to connect back so I don't know what Nokia
PC Suite service actually would like to hear..

I think the SP service required by Guido might be channel 3 in this case.

iain
-------------- next part --------------
HCI sniffer - Bluetooth packet analyzer ver 1.42-netbt
< HCI Command: Create Connection (0x01|0x0005) plen 13
    bdaddr 00:16:BC:*:*:* ptype 0xcc18 rswitch 0x01 clkoffset 0x06a9
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 
> HCI Event: Command Status (0x0f) plen 4
    Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 45 bdaddr 00:16:BC:*:*:* type ACL encrypt 0x00
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
    handle 45 policy 0x07
    Link policy: RSWITCH HOLD SNIFF 
< ACL data: handle 45 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 3 scid 0x0042
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 45 packets 1
> HCI Event: Command Complete (0x0e) plen 6
    Write Link Policy Settings (0x02|0x000d) ncmd 1
    status 0x00 handle 45
< HCI Command: Read Clock Offset (0x01|0x001f) plen 2
    handle 45
> HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
    bdaddr 00:16:BC:*:*:* mode 1
> HCI Event: Max Slots Change (0x1b) plen 3
    handle 45 slots 5
> HCI Event: Command Status (0x0f) plen 4
    Read Clock Offset (0x01|0x001f) status 0x00 ncmd 0
> HCI Event: Command Status (0x0f) plen 4
    Unknown (0x00|0x0000) status 0x00 ncmd 1
> HCI Event: Read Clock Offset Complete (0x1c) plen 5
    status 0x00 handle 45 clkoffset 0x06a1
> ACL data: handle 45 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0042 result 0 status 0
      Connection successful
< ACL data: handle 45 flags 0x02 dlen 12
    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
> ACL data: handle 45 flags 0x02 dlen 16
    L2CAP(s): Config req: dcid 0x0042 flags 0x00 clen 4
      MTU 32772 
< ACL data: handle 45 flags 0x02 dlen 14
    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
      Success
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 45 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 45 packets 1
> ACL data: handle 45 flags 0x02 dlen 14
    L2CAP(s): Config rsp: scid 0x0042 flags 0x00 result 0 clen 0
      Success
< ACL data: handle 45 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c 
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 45 packets 1
> ACL data: handle 45 flags 0x02 dlen 8
    L2CAP(d): cid 0x0042 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7 
< ACL data: handle 45 flags 0x02 dlen 18
    L2CAP(d): cid 0x0040 len 14 [psm 3]
      RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
      dlci 30 frame_type 0 credit_flow 15 pri 31 ack_timer 0
      frame_size 127 max_retrans 0 credits 7
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 45 packets 1
> ACL data: handle 45 flags 0x02 dlen 18
    L2CAP(d): cid 0x0042 len 14 [psm 3]
      RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8
      dlci 30 frame_type 0 credit_flow 14 pri 31 ack_timer 0
      frame_size 127 max_retrans 0 credits 0
< ACL data: handle 45 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): SABM: cr 1 dlci 30 pf 1 ilen 0 fcs 0x6d 
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 45 packets 1
> HCI Event: Link Key Request (0x17) plen 6
    bdaddr 00:16:BC:*:*:*
< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
    bdaddr 00:16:BC:*:*:* key ********************************
> HCI Event: Command Complete (0x0e) plen 10
    Link Key Request Reply (0x01|0x000b) ncmd 1
    status 0x00 bdaddr 00:16:BC:*:*:*
> HCI Event: Encrypt Change (0x08) plen 4
    status 0x00 handle 45 encrypt 0x01
> ACL data: handle 45 flags 0x02 dlen 8
    L2CAP(d): cid 0x0042 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 30 pf 1 ilen 0 fcs 0xa6 
< ACL data: handle 45 flags 0x02 dlen 13
    L2CAP(d): cid 0x0040 len 9 [psm 3]
      RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 5 fcs 0x70 mcc_len 3
      dlci 30 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 1
> ACL data: handle 45 flags 0x02 dlen 12
    L2CAP(d): cid 0x0042 len 8 [psm 3]
      RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
      dlci 30 fc 0 rtc 1 rtr 1 ic 0 dv 0 b1 1 b2 0 b3 0 len 1
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 45 packets 1
< ACL data: handle 45 flags 0x02 dlen 12
    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
      dlci 30 fc 0 rtc 1 rtr 1 ic 0 dv 0 b1 1 b2 0 b3 0 len 1
> ACL data: handle 45 flags 0x02 dlen 9
    L2CAP(d): cid 0x0042 len 5 [psm 3]
      RFCOMM(d): UIH: cr 0 dlci 30 pf 1 ilen 0 fcs 0x37 credits 10
> ACL data: handle 45 flags 0x02 dlen 12
    L2CAP(d): cid 0x0042 len 8 [psm 3]
      RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
      dlci 30 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 1
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 45 packets 1
< ACL data: handle 45 flags 0x02 dlen 10
    L2CAP(d): cid 0x0040 len 6 [psm 3]
      RFCOMM(d): UIH: cr 1 dlci 30 pf 1 ilen 1 fcs 0xed credits 25
      0D 
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 45 packets 1
> ACL data: handle 45 flags 0x02 dlen 8
    L2CAP(d): cid 0x0042 len 4 [psm 3]
      RFCOMM(s): DISC: cr 0 dlci 30 pf 1 ilen 0 fcs 0xed 
< ACL data: handle 45 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 0 dlci 30 pf 1 ilen 0 fcs 0xc7 
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 45 packets 1
> ACL data: handle 45 flags 0x02 dlen 8
    L2CAP(d): cid 0x0042 len 4 [psm 3]
      RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c 
< ACL data: handle 45 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6 
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 45 packets 1
< ACL data: handle 45 flags 0x02 dlen 12
    L2CAP(s): Disconn req: dcid 0x0040 scid 0x0042
> ACL data: handle 45 flags 0x02 dlen 12
    L2CAP(s): Disconn req: dcid 0x0042 scid 0x0040
< ACL data: handle 45 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0042 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 45 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 45 packets 1
> ACL data: handle 45 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0042
< HCI Command: Disconnect (0x01|0x0006) plen 3
    handle 45 reason 0x13
    Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 45 reason 0x16
    Reason: Connection Terminated by Local Host
From mad at madpilot.net  Tue Nov  4 12:56:12 2008
From: mad at madpilot.net (Guido Falsi)
Date: Tue Nov  4 12:56:19 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <1225821264.107584.759.nullmailer@galant.ukfsn.org>
References: <20081104111947.GB62907@megatron.madpilot.net>
	<1225799105.807983.1164.nullmailer@galant.ukfsn.org>
	<20081104135107.GA64776@megatron.madpilot.net>
	<1225821264.107584.759.nullmailer@galant.ukfsn.org>
Message-ID: <4910B6E6.7070206@madpilot.net>

Iain Hibbert wrote:
> On Tue, 4 Nov 2008, Guido Falsi wrote:
> 

> 
> and I see that connecting to DUN gives me an AT command interpreter as
> does SP on 3 (COM 1) but connecting to the SP on 15 (Nokia PC Suite)
> doesn't. Thats using NetBSD though the program is not much different.

Yes, My code is doing a similar thing, but should just return the 
correct rfchannel.

I've not been using C for some time though and got bitten by a stupid 
error(2 uninitialized variables).

Now it's skipping channels it should skip.

> 
> can you connect to channel 1 (Dialup Networking) with rfcomm_sppd?  That
> should definitely take AT commands..

Ok, I got it to work, but I had to make rfcomm_sppd attach the line to a 
tty and the use cu on that tty. Most probably my terminal emulator lacks 
some knowledge and rfcomm_sppd is making no translation.

I was getting just echo of whatever I wrote.

> 
> btw, didn't you say before that gnokii is supposed to be discarding "Nokia
> PC Suite" ?  (actually, that was why I added the "Service Name" handling,
> so I could see what my phone had :)
> 

As I said, that was my mistake. Anyway I thank you a lot because you 
gave me the idea where to look for mistakes. I should be able to get 
gnokii to work now. Thank you a lot again!

-- 
Guido Falsi <mad@madpilot.net>
From mad at madpilot.net  Tue Nov  4 14:20:11 2008
From: mad at madpilot.net (Guido Falsi)
Date: Tue Nov  4 14:20:18 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <4910B6E6.7070206@madpilot.net>
References: <20081104111947.GB62907@megatron.madpilot.net>	<1225799105.807983.1164.nullmailer@galant.ukfsn.org>	<20081104135107.GA64776@megatron.madpilot.net>	<1225821264.107584.759.nullmailer@galant.ukfsn.org>
	<4910B6E6.7070206@madpilot.net>
Message-ID: <4910CA97.6030708@madpilot.net>

Guido Falsi wrote:

> As I said, that was my mistake. Anyway I thank you a lot because you 
> gave me the idea where to look for mistakes. I should be able to get 
> gnokii to work now. Thank you a lot again!
> 

I've just submitted a PR for the gnokii port. If someone feels like 
checking my work(it does need checking I think) it's here:

http://www.freebsd.org/cgi/query-pr.cgi?pr=128589

Thank you again for your help and work on the bluetooth stack!

-- 
Guido Falsi <mad@madpilot.net>
From selena12321 at gmail.com  Tue Nov  4 23:25:29 2008
From: selena12321 at gmail.com (angelinalove)
Date: Tue Nov  4 23:25:36 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <20081104111947.GB62907@megatron.madpilot.net>
References: <20081104111947.GB62907@megatron.madpilot.net>
Message-ID: <20337030.post@talk.nabble.com>


I am very big fan of reliable nokia phones feel like to purchasing nokia n96
but I can't afford right now so I am planning to buy Nintenao wii mario cart
from http://www.blueunplugged.com/p.aspx?p=122678
 but in coming day I will pic n96 very soon.




-- 
View this message in context: http://www.nabble.com/RFComm-behaviour-with-nokia-mobiles-tp20320332p20337030.html
Sent from the freebsd-bluetooth mailing list archive at Nabble.com.

From plunky at rya-online.net  Fri Nov  7 13:00:06 2008
From: plunky at rya-online.net (Iain Hibbert)
Date: Fri Nov  7 13:00:12 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <4910CA97.6030708@madpilot.net>
References: <20081104111947.GB62907@megatron.madpilot.net>
	<1225799105.807983.1164.nullmailer@galant.ukfsn.org>
	<20081104135107.GA64776@megatron.madpilot.net>
	<1225821264.107584.759.nullmailer@galant.ukfsn.org>
	<4910B6E6.7070206@madpilot.net> <4910CA97.6030708@madpilot.net>
Message-ID: <1226091521.039371.399.nullmailer@galant.ukfsn.org>

On Tue, 4 Nov 2008, Guido Falsi wrote:

> Guido Falsi wrote:
>
> > As I said, that was my mistake. Anyway I thank you a lot because you gave me
> > the idea where to look for mistakes. I should be able to get gnokii to work
> > now. Thank you a lot again!
>
> I've just submitted a PR for the gnokii port. If someone feels like checking
> my work(it does need checking I think) it's here:

The attribute ID list should be in ascending order according to the
specification. This means though that some logic could be wrong because
the protocol descriptor list for any given service class would likely
appear before the service name in the response attribute list and you
would use the wrong channel..

probably you should do it like:

	channel = -1;

	switch (attribute) {
	case PROTOCOL_DESCRIPTOR_LIST
		channel = <...>;
		break;

	case SERVICE_NAME
		if (channel == -1)
			break;

		str = <...>;

		if (strncmp(str, "...")) {
			channel = -1;
			break;
		}

		return success;
	}

?

also, instead of providing two calls to the find_service_channel()
function, just put

#ifdef SDP_SERVICE_CLASS_SERIAL_PORT
#define SERIAL_PORT_SVCLASS_ID SDP_SERVICE_CLASS_SERIAL_PORT
#endif

at the top which cuts down on unreadable alternatives?

iain
From mad at madpilot.net  Fri Nov  7 13:20:23 2008
From: mad at madpilot.net (Guido Falsi)
Date: Fri Nov  7 13:20:29 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <1226091521.039371.399.nullmailer@galant.ukfsn.org>
References: <20081104111947.GB62907@megatron.madpilot.net>
	<1225799105.807983.1164.nullmailer@galant.ukfsn.org>
	<20081104135107.GA64776@megatron.madpilot.net>
	<1225821264.107584.759.nullmailer@galant.ukfsn.org>
	<4910B6E6.7070206@madpilot.net> <4910CA97.6030708@madpilot.net>
	<1226091521.039371.399.nullmailer@galant.ukfsn.org>
Message-ID: <4914B113.60303@madpilot.net>

Iain Hibbert wrote:
> On Tue, 4 Nov 2008, Guido Falsi wrote:
> 
>> Guido Falsi wrote:
>>
>>> As I said, that was my mistake. Anyway I thank you a lot because you gave me
>>> the idea where to look for mistakes. I should be able to get gnokii to work
>>> now. Thank you a lot again!
>> I've just submitted a PR for the gnokii port. If someone feels like checking
>> my work(it does need checking I think) it's here:
> 
> The attribute ID list should be in ascending order according to the
> specification. This means though that some logic could be wrong because
> the protocol descriptor list for any given service class would likely
> appear before the service name in the response attribute list and you
> would use the wrong channel..

Uhm, I did not get this detail in the specification.

> 
> probably you should do it like:
> 
> 	channel = -1;
> 
> 	switch (attribute) {
> 	case PROTOCOL_DESCRIPTOR_LIST
> 		channel = <...>;
> 		break;
> 
> 	case SERVICE_NAME
> 		if (channel == -1)
> 			break;
> 
> 		str = <...>;
> 
> 		if (strncmp(str, "...")) {
> 			channel = -1;
> 			break;
> 		}
> 
> 		return success;
> 	}
> 
> ?

I'll check it.

> 
> also, instead of providing two calls to the find_service_channel()
> function, just put
> 
> #ifdef SDP_SERVICE_CLASS_SERIAL_PORT
> #define SERIAL_PORT_SVCLASS_ID SDP_SERVICE_CLASS_SERIAL_PORT
> #endif
> 
> at the top which cuts down on unreadable alternatives?

Gnokii author also required this before importing the patch upstream, so 
I've already fixed this.

The original software also has some glue functions put there for 
compatibility which are not needed, so I'm going to remove them.

can you or Maksim confirm FreeBSD has always had(expecially in 6.x) 
bt_aton(), str2ba() and bacpy() ?

-- 
Guido Falsi <mad@madpilot.net>
From maksim.yevmenkin at gmail.com  Fri Nov  7 14:07:31 2008
From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin)
Date: Fri Nov  7 14:08:16 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <4914B113.60303@madpilot.net>
References: <20081104111947.GB62907@megatron.madpilot.net>
	<1225799105.807983.1164.nullmailer@galant.ukfsn.org>
	<20081104135107.GA64776@megatron.madpilot.net>
	<1225821264.107584.759.nullmailer@galant.ukfsn.org>
	<4910B6E6.7070206@madpilot.net> <4910CA97.6030708@madpilot.net>
	<1226091521.039371.399.nullmailer@galant.ukfsn.org>
	<4914B113.60303@madpilot.net>
Message-ID: <bb4a86c70811071407l42e2ea74oe403299b4fd3f22e@mail.gmail.com>

Hi Guido,

> can you or Maksim confirm FreeBSD has always had(expecially in 6.x)
> bt_aton(), str2ba() and bacpy() ?

yes, those were included very early.

thanks,
max
From plunky at rya-online.net  Fri Nov  7 14:32:51 2008
From: plunky at rya-online.net (Iain Hibbert)
Date: Fri Nov  7 14:32:58 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <4914B113.60303@madpilot.net>
References: <20081104111947.GB62907@megatron.madpilot.net>
	<1225799105.807983.1164.nullmailer@galant.ukfsn.org>
	<20081104135107.GA64776@megatron.madpilot.net>
	<1225821264.107584.759.nullmailer@galant.ukfsn.org>
	<4910B6E6.7070206@madpilot.net> <4910CA97.6030708@madpilot.net>
	<1226091521.039371.399.nullmailer@galant.ukfsn.org>
	<4914B113.60303@madpilot.net>
Message-ID: <1226097099.328979.788.nullmailer@galant.ukfsn.org>

On Fri, 7 Nov 2008, Guido Falsi wrote:

> Iain Hibbert wrote:
> > The attribute ID list should be in ascending order according to the
> > specification. This means though that some logic could be wrong because
> > the protocol descriptor list for any given service class would likely
> > appear before the service name in the response attribute list and you
> > would use the wrong channel..
>
> Uhm, I did not get this detail in the specification.

You can find this in the small print of the SDP spec sections relating to
ServiceSearch and ServiceSearchAttribute requests, in the AttributeIDList
box.

I guess its so that a server can do a straight pass through search without
having to loop up and down the list, but I don't know if that would work
out simpler or not in practice. Obviously the Nokia people thought not, as
it worked anyway :)

iain
From mad at madpilot.net  Fri Nov  7 17:03:12 2008
From: mad at madpilot.net (Guido Falsi)
Date: Fri Nov  7 17:03:19 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <1226097099.328979.788.nullmailer@galant.ukfsn.org>
References: <20081104111947.GB62907@megatron.madpilot.net>
	<1225799105.807983.1164.nullmailer@galant.ukfsn.org>
	<20081104135107.GA64776@megatron.madpilot.net>
	<1225821264.107584.759.nullmailer@galant.ukfsn.org>
	<4910B6E6.7070206@madpilot.net> <4910CA97.6030708@madpilot.net>
	<1226091521.039371.399.nullmailer@galant.ukfsn.org>
	<4914B113.60303@madpilot.net>
	<1226097099.328979.788.nullmailer@galant.ukfsn.org>
Message-ID: <4914E54B.4060206@madpilot.net>

Iain Hibbert wrote:
> On Fri, 7 Nov 2008, Guido Falsi wrote:
> 
>> Iain Hibbert wrote:
>>> The attribute ID list should be in ascending order according to
>>> the specification. This means though that some logic could be
>>> wrong because the protocol descriptor list for any given service
>>> class would likely appear before the service name in the response
>>> attribute list and you would use the wrong channel..
>> Uhm, I did not get this detail in the specification.
> 
> You can find this in the small print of the SDP spec sections
> relating to ServiceSearch and ServiceSearchAttribute requests, in the
> AttributeIDList box.
> 
> I guess its so that a server can do a straight pass through search
> without having to loop up and down the list, but I don't know if that
> would work out simpler or not in practice. Obviously the Nokia people
> thought not, as it worked anyway :)
> 

After some reading, some coding and some experimenting I think I found
what is happening.

I have this code(I hope mozilla will not mangle this too much):

uint32_t attrs[] =
{
SDP_ATTR_RANGE(
SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID+SDP_ATTR_SERVICE_NAME_OFFSET,
SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID+SDP_ATTR_SERVICE_NAME_OFFSET),
SDP_ATTR_RANGE(
SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST,
SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST),
};

so I define 2 ranges with a single attribute in each. This one defines 
the order in which objects are returned.

Since I think code written the way you suggested is cleaner and more 
readable I'll just swap the two ranges and have it work the way you said.

I think FreeBSD's sdp is making 2 requests in this case...Or maybe 
forcing the order to be the same as the request.

-- 
Guido Falsi <mad@madpilot.net>
From plunky at rya-online.net  Sat Nov  8 01:17:24 2008
From: plunky at rya-online.net (Iain Hibbert)
Date: Sat Nov  8 01:17:31 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <4914E54B.4060206@madpilot.net>
References: <20081104111947.GB62907@megatron.madpilot.net>
	<1225799105.807983.1164.nullmailer@galant.ukfsn.org>
	<20081104135107.GA64776@megatron.madpilot.net>
	<1225821264.107584.759.nullmailer@galant.ukfsn.org>
	<4910B6E6.7070206@madpilot.net> <4910CA97.6030708@madpilot.net>
	<1226091521.039371.399.nullmailer@galant.ukfsn.org>
	<4914B113.60303@madpilot.net>
	<1226097099.328979.788.nullmailer@galant.ukfsn.org>
	<4914E54B.4060206@madpilot.net>
Message-ID: <1226135769.665964.502.nullmailer@galant.ukfsn.org>

On Sat, 8 Nov 2008, Guido Falsi wrote:

> I have this code(I hope mozilla will not mangle this too much):
>
> uint32_t attrs[] =
> {
> SDP_ATTR_RANGE(
> SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID+SDP_ATTR_SERVICE_NAME_OFFSET,
> SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID+SDP_ATTR_SERVICE_NAME_OFFSET),
> SDP_ATTR_RANGE(
> SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST,
> SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST),
> };
>
> so I define 2 ranges with a single attribute in each. This one defines the
> order in which objects are returned.

although the sdp lib function does collapse empty ranges into single
attributes to save space in the outgoing request..

> I think FreeBSD's sdp is making 2 requests in this case...Or maybe forcing the
> order to be the same as the request.

No, it does use a single ServiceSearchAttribute but I think its just that
the Nokia server iterates over the AttributeIDList with a pass through the
server record each time for attributes that match:

	for (i = 0; i < ail_length; i++)
		for (j = 0; j < record_length; j++)
			if (ail[i] == rec[j])
				add_attribute(rec[j])
				break;

Because both lists are supposed to be in ascending order though, it is
possible to cut that down to a single pass with an eye on each list:

	i = 0, j = 0
next:
	if (ail[i] == rec[j])
		add_attribute(rec[j]);
		i++, j++;
	else if (ail[i] < rec[j])
		i++;
	else if (ail[i] > rec[j])
		j++;
	if (i == ail_length)
		goto done;
	if (j == rec_length)
		goto done;
	goto next;
done:

Which is less processor intensive, and often with an embedded device
(perhaps not in the modern world :) it is even easier to just hardwire
such a search and probably that is what they are providing for in the
spec.

One thing that the current library code does not provide for is that the
ServiceSearchAttribute response is parsed into the sdp_attr_t array but
the caller has no way to know which record each attribute came from, so
that can cause problems when more than one record is matched.  You might
also want to consider the case where a Serial Port service is matched that
does not have a Service Name field. Do you match it or ignore it?

iain

PS all pseudo code comes with no guarantee of correctness!

PPS wtf is "m-Router connectivity" anyway?
From mad at madpilot.net  Sat Nov  8 04:20:50 2008
From: mad at madpilot.net (Guido Falsi)
Date: Sat Nov  8 04:21:05 2008
Subject: RFComm behaviour with nokia mobiles
In-Reply-To: <1226135769.665964.502.nullmailer@galant.ukfsn.org>
References: <20081104111947.GB62907@megatron.madpilot.net>
	<1225799105.807983.1164.nullmailer@galant.ukfsn.org>
	<20081104135107.GA64776@megatron.madpilot.net>
	<1225821264.107584.759.nullmailer@galant.ukfsn.org>
	<4910B6E6.7070206@madpilot.net> <4910CA97.6030708@madpilot.net>
	<1226091521.039371.399.nullmailer@galant.ukfsn.org>
	<4914B113.60303@madpilot.net>
	<1226097099.328979.788.nullmailer@galant.ukfsn.org>
	<4914E54B.4060206@madpilot.net>
	<1226135769.665964.502.nullmailer@galant.ukfsn.org>
Message-ID: <4915841D.1060503@madpilot.net>

Iain Hibbert wrote:

>> I think FreeBSD's sdp is making 2 requests in this case...Or maybe forcing the
>> order to be the same as the request.
> 
> No, it does use a single ServiceSearchAttribute but I think its just that
> the Nokia server iterates over the AttributeIDList with a pass through the
> server record each time for attributes that match:
> 

Now I understand it. An old sony ericcson T610 is acting the same as the 
2 nokias I tried. Anyway to be on the safe side, as I said, i defined 
the request list in ascending order and expect answers in ascending order.


> One thing that the current library code does not provide for is that the
> ServiceSearchAttribute response is parsed into the sdp_attr_t array but
> the caller has no way to know which record each attribute came from, so
> that can cause problems when more than one record is matched.  You might
> also want to consider the case where a Serial Port service is matched that
> does not have a Service Name field. Do you match it or ignore it?
> 

original gnokii code is ignoring services without a name, so I'm 
ignoring them. I don't know exactly the chance of such a situation., 
Keep in mind that gnokii is interested in talking just to mobile phones, 
not to any kind of bluetooth device, so the function does not have any 
need to be too generic.

> 
> PPS wtf is "m-Router connectivity" anyway?

I don't have the slightest idea :P Mobile phones come with a lot of 
strange services...

Googleing a little it looks like some kind of routing service used by 
nokia PC suite to share more services on just one logical connection.


-- 
Guido Falsi <mad@madpilot.net>
From maksim.yevmenkin at gmail.com  Sun Nov  9 10:56:04 2008
From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin)
Date: Sun Nov  9 10:56:11 2008
Subject: Bluetooth PAN daemon
In-Reply-To: <1226244908.379168.1357.nullmailer@galant.ukfsn.org>
References: <1218640640.464572.1418.nullmailer@galant.ukfsn.org>
	<bb4a86c70808130939p1f0cccd6mc99737d1aee6c485@mail.gmail.com>
	<1218654792.685823.650.nullmailer@galant.ukfsn.org>
	<bb4a86c70808131237q1e9d4c31j24fb9f99bcb3fdc@mail.gmail.com>
	<1226244908.379168.1357.nullmailer@galant.ukfsn.org>
Message-ID: <bb4a86c70811091056k3b4bf900y1f2650fb6e3e6102@mail.gmail.com>

On Sun, Nov 9, 2008 at 7:35 AM, Iain Hibbert <plunky@rya-online.net> wrote:
> On Wed, 13 Aug 2008, Maksim Yevmenkin wrote:
>
>> ok, for now i will install it from the ports and try to make it work.
>
> Hi Max, just out of interest .. did you get that btpand working?

yes, i did. just need to get my act together and commit it :)

> (Some guy was asking about it for OpenBSD but they don't have a tap(4)
> device)

hmmm... i think openbsd has something like tap(4). i will have to check.

thanks,
max
From vasilicht at gmail.com  Tue Nov 18 11:24:09 2008
From: vasilicht at gmail.com (Rodion Turlac)
Date: Tue Nov 18 11:24:16 2008
Subject: bluesoleil dongle and "ubt0 - Control request failed"
Message-ID: <23295d220811181100y46748247l4572300c101087d7@mail.gmail.com>

Hello.
I have tried to setup bluesoleil dongle on freebsd 7.1-pre.
I incresed some variables that reduced error outputs:
sysctl net.bluetooth.hci.command_timeout=30
sysctl net.bluetooth.hci.sockets.raw.ioctl_timeout=30

But I still got error messages like that ubt_request_complete2: ubt0 -
Control request failed. TIMEOUT (15) and ask for help.
I have include outputs of diagnostic commands.

rad-home-60# ngctl types
There are 7 total types:
      Type name   Number of living nodes
      ---------   ----------------------
         socket       1
     btsock_l2c       1
 btsock_l2c_raw       1
 btsock_hci_raw       1
          l2cap       1
            hci       1
            ubt       1

rad-home-60# ngctl li
There are 7 total nodes:
  Name: btsock_l2c_raw  Type: btsock_l2c_raw  ID: 00000003   Num hooks: 1
  Name: ubt0hci         Type: hci             ID: 00000006   Num hooks: 3
  Name: btsock_hci_raw  Type: btsock_hci_raw  ID: 00000002   Num hooks: 1
  Name: ubt0l2cap       Type: l2cap           ID: 0000000a   Num hooks: 3
  Name: ngctl1049       Type: socket          ID: 00000011   Num hooks: 0
  Name: btsock_l2c      Type: btsock_l2c      ID: 00000004   Num hooks: 1
  Name: ubt0            Type: ubt             ID: 00000001   Num hooks: 1

rad-home-60# ngctl status ubt0:
Status for "ubt0:":
Hook: hook
Flags: 0x30
Debug: 3
CMD queue: [have:0,max:12]
ACL queue: [have:0,max:12]
SCO queue: [have:0,max:12]

rad-home-60# ngctl status ubt0hci:
Status for "ubt0hci:":
bdaddr 11:11:11:11:11:11
Hooks  drv acl  raw
State  0x3
Queue  cmd:0
Buffer cmd:1,acl:8,8,678,sco:10,10,48

During start command /etc/rc.d/bluetooth start ubt0 there is no
output, I made dump with hcidump.

rad-home-60# hcidump -tx
HCIDump - HCI packet analyzer ver 1.5
device: any snap_len: 65535 filter: 0xffffffff
1227033020.314621 < HCI Command: Read BD ADDR(0x04|0x0009) plen 0
1227033020.317276 > HCI Event: Command Complete(0x0e) plen 10
  01 09 10 00 11 11 11 11 11 11
1227033020.319685 < HCI Command: Read Local Supported
Features(0x04|0x0003) plen 0
1227033025.319434 > HCI Event: Command Complete(0x0e) plen 12
  01 03 10 00 BF FE 8D 78 08 18 00 00
1227033025.321803 < HCI Command: Read Buffer Size(0x04|0x0005) plen 0
1227033030.322611 > HCI Event: Command Complete(0x0e) plen 11
  01 05 10 00 A6 02 30 08 00 0A 00
1227033030.353647 < HCI Command: Write Scan Enable(0x03|0x001a) plen 1
  03
1227033035.325771 > HCI Event: Command Complete(0x0e) plen 4
  01 1A 0C 00
1227033035.328136 < HCI Command: Write Class of Device(0x03|0x0024) plen 3
  0C 01 FF
1227033040.327931 > HCI Event: Command Complete(0x0e) plen 4
  01 24 0C 00
1227033040.330280 < HCI Command: Write Authentication Enable(0x03|0x0020) plen 1
  00
1227033045.331097 > HCI Event: Command Complete(0x0e) plen 4
  01 20 0C 00
1227033045.333341 < HCI Command: Write Encryption Mode(0x03|0x0022) plen 1
  00
1227033050.334260 > HCI Event: Command Complete(0x0e) plen 4
  01 22 0C 00
1227033050.338587 < HCI Command: Change Local Name(0x03|0x0013) plen 248
  72 61 64 2D 68 6F 6D 65 2D 36 30 2E 72 61 64 2E 63 6F 6D 20
  28 75 62 74 30 29 00 28 00 64 08 28 84 EB BF BF D3 C7 05 28
  74 EB BF BF 68 EB BF BF 01 00 00 00 00 60 08 28 AC 9A B0 07
  32 87 04 08 00 64 08 28 20 EB BF BF 03 00 00 00 03 00 00 00
  00 64 08 28 14 F7 07 28 20 A0 08 28 00 60 08 28 C4 EB BF BF
  D3 C7 05 28 B4 EB BF BF 20 A0 08 28 01 00 00 00 FF EB 05 28
  00 00 00 00 E4 84 04 08 32 87 04 08 38 EA 05 28 80 A0 08 28
  14 F7 07 28 C4 EB BF BF 76 EC 05 28 80 A0 08 28 14 F7 07 28
  04 EC BF BF E8 C8 05 28 24 3D 08 28 01 00 00 00 F4 EB BF BF
  01 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 28 EC BF BF
  DF 7F 0C 28 14 EC BF BF 00 64 08 28 D4 EC BF BF 7D 85 16 28
  B0 EC BF BF 04 00 00 00 24 87 05 08 D4 EC BF BF 00 00 00 00
  00 00 00 00 B0 EC BF BF
1227033055.344425 > HCI Event: Command Complete(0x0e) plen 4
  01 13 0C 00

rad-home-60# uname -a
FreeBSD rad-home-60.rad.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4:
Sat Nov 15 20:40:18 EET 2008
root@rad-home-60.rad.com:/usr/obj/usr/src/sys/KERNEL  i386

rad-home-60# usbdevs -dv
Controller /dev/usb0:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),
Intel(0x0000), rev 1.00
  uhub0
 port 1 powered
 port 2 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),
Intel(0x0000), rev 1.00
  uhub1
 port 1 powered
 port 2 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),
Intel(0x0000), rev 1.00
  uhub2
 port 1 powered
 port 2 powered
Controller /dev/usb3:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),
Intel(0x0000), rev 1.00
  uhub3
 port 1 addr 2: full speed, self powered, config 1, ISSCBTA(0x1001),
vendor 0x1131(0x1131), rev 3.73
   ubt0
 port 2 powered
Controller /dev/usb4:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000),
Intel(0x0000), rev 1.00
  uhub4
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 powered
 port 6 powered
 port 7 powered
 port 8 powered

rad-home-60# dmesg
Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-PRERELEASE #4: Sat Nov 15 20:40:18 EET 2008
    root@rad-home-60.rad.com:/usr/obj/usr/src/sys/KERNEL
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Celeron(R) CPU 2.80GHz (2793.19-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf49  Stepping = 9
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x441d<SSE3,DTES64,MON,DS_CPL,CNXT-ID,xTPR>
real memory  = 1609756672 (1535 MB)
avail memory = 1559703552 (1487 MB)
ACPI APIC Table: <INTEL  D865GBF >
ioapic0 <Version 2.0> irqs 0-23 on motherboard
acpi0: <INTEL D865GBF> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 5ff00000 (3) failed
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> mem
0xfd000000-0xfdffffff,0xc0000000-0xcfffffff,0xfc000000-0xfcffffff irq
16 at device 0.0 on pci1
nvidia0: <Unknown> on vgapci0
vgapci0: child nvidia0 requested pci_enable_busmaster
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: child nvidia0 requested pci_enable_io
nvidia0: [GIANT-LOCKED]
nvidia0: [ITHREAD]
uhci0: <Intel 82801EB (ICH5) USB controller USB-A> port 0xe000-0xe01f
irq 16 at device 29.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <Intel 82801EB (ICH5) USB controller USB-A> on uhci0
usb0: USB revision 1.0
uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: <Intel 82801EB (ICH5) USB controller USB-B> port 0xe400-0xe41f
irq 19 at device 29.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <Intel 82801EB (ICH5) USB controller USB-B> on uhci1
usb1: USB revision 1.0
uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2: <Intel 82801EB (ICH5) USB controller USB-C> port 0xe800-0xe81f
irq 18 at device 29.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <Intel 82801EB (ICH5) USB controller USB-C> on uhci2
usb2: USB revision 1.0
uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
uhci3: <Intel 82801EB (ICH5) USB controller USB-D> port 0xec00-0xec1f
irq 16 at device 29.3 on pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb3: <Intel 82801EB (ICH5) USB controller USB-D> on uhci3
usb3: USB revision 1.0
uhub3: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
ehci0: <Intel 82801EB/R (ICH5) USB 2.0 controller> mem
0xfebffc00-0xfebfffff irq 23 at device 29.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb4: waiting for BIOS to give up control
usb4: timed out waiting for BIOS
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
usb4: <Intel 82801EB/R (ICH5) USB 2.0 controller> on ehci0
usb4: USB revision 2.0
uhub4: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4
uhub4: 8 ports with 8 removable, self powered
pcib2: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci2: <ACPI PCI bus> on pcib2
rl0: <RealTek 8139 10/100BaseTX> port 0xc800-0xc8ff mem
0xfeaffc00-0xfeaffcff irq 19 at device 3.0 on pci2
miibus0: <MII bus> on rl0
rlphy0: <RealTek internal media interface> PHY 0 on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl0: Ethernet address: 00:e0:4c:39:10:b2
rl0: [ITHREAD]
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH5 UDMA100 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on
pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
ichsmb0: <Intel 82801EB (ICH5) SMBus controller> port 0xdc00-0xdc1f
irq 17 at device 31.3 on pci0
ichsmb0: [GIANT-LOCKED]
ichsmb0: [ITHREAD]
smbus0: <System Management Bus> on ichsmb0
pcm0: <Intel ICH5 (82801EB)> mem
0xfebff800-0xfebff9ff,0xfebff400-0xfebff4ff irq 17 at device 31.5 on
pci0
pcm0: [ITHREAD]
pcm0: primary codec not ready!
pcm0: <Analog Devices AD1985 AC97 Codec>
acpi_button0: <Sleep Button> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse, device ID 3
fdc0: <floppy drive controller> port
0x3f0-0x3f1,0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
cpu0: <ACPI CPU> on acpi0
acpi_throttle0: <ACPI CPU Throttling> on cpu0
pmtimer0 on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
ubt0: <vendor 0x1131 ISSCBTA, class 224/1, rev 1.10/3.73, addr 2> on uhub3
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83,
isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294
Timecounter "TSC" frequency 2793193168 Hz quality 800
Timecounters tick every 1.000 msec
ad0: 152627MB <WDC WD1600AAJB-22PVA0 00.07H00> at ata0-master UDMA100
ad1: 114473MB <Seagate ST3120814A 3.AAH> at ata0-slave UDMA100
acd0: CDRW <ASUS CB-5216A/1.06> at ata1-master UDMA100
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
cd0 at ata1 bus 0 target 0 lun 0
cd0: <ASUS CB-5216A 1.06> Removable CD-ROM SCSI-0 device
cd0: 100.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not
present - tray closed
GEOM_LABEL: Label for provider ad0s1 is msdosfs/DOS.
GEOM_LABEL: Label for provider ad0s5 is ntfs/W2K.
GEOM_LABEL: Label for provider ad0s6 is ntfs/DATA.
GEOM_LABEL: Label for provider ad0s7 is ntfs/VIDEO.
GEOM_LABEL: Label for provider ad1s5 is ntfs/GAMES.
GEOM_LABEL: Label for provider ad1s6 is ntfs/RADIK.
GEOM_JOURNAL: Journal 761889422: ad1s3f contains data.
GEOM_JOURNAL: Journal 761889422: ad1s3f contains journal.
GEOM_JOURNAL: Journal ad1s3f clean.
Trying to mount root from ufs:/dev/ad1s3a
WARNING: attempt to net_add_domain(bluetooth) after domainfinalize()
WARNING: attempt to net_add_domain(netgraph) after domainfinalize()
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
From maksim.yevmenkin at gmail.com  Wed Nov 19 10:12:23 2008
From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin)
Date: Wed Nov 19 10:12:36 2008
Subject: bluesoleil dongle and "ubt0 - Control request failed"
In-Reply-To: <bb4a86c70811191011v3fff4923m96924b511bc4c088@mail.gmail.com>
References: <23295d220811181100y46748247l4572300c101087d7@mail.gmail.com>
	<bb4a86c70811191011v3fff4923m96924b511bc4c088@mail.gmail.com>
Message-ID: <bb4a86c70811191012t1b178ac2s159f5c3825f82c19@mail.gmail.com>

Hi,

 On 11/18/08, Rodion Turlac <vasilicht@gmail.com> wrote:
 > Hello.
 >  I have tried to setup bluesoleil dongle on freebsd 7.1-pre.
 >  I incresed some variables that reduced error outputs:
 >  sysctl net.bluetooth.hci.command_timeout=30
 >  sysctl net.bluetooth.hci.sockets.raw.ioctl_timeout=30
 >
 >  But I still got error messages like that ubt_request_complete2: ubt0 -
 >  Control request failed. TIMEOUT (15) and ask for help.
 >  I have include outputs of diagnostic commands.


hmm... very strange... according to the dumps everything seems to be
 normal. at least in hci dump i can see successful responses to
 commands we submit.

 is  device's bd_addr really 11:11:11:11:11:11 or you just changed it?

 [...]


 >  ubt0: <vendor 0x1131 ISSCBTA, class 224/1, rev 1.10/3.73, addr 2> on uhub3
 >  ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
 >  ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83,
 >  isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294


this particular dongle known to be a bit weird. please search for
 ISSCBTA in freebsd list archives.

 it also could be a problem with short control usb transfers, esp. on
 ehci controllers. so my suggestions are

 - try to plug the device in different ports if there is an external
 usb hub - try without it

 - try to comment 'reset' command in /etc/rc.d/bluetooth

 - play w/bios settings (anything related to usb2.0 if you have
 anything like that)

 thanks,
 max
From vasilicht at gmail.com  Sat Nov 22 22:38:35 2008
From: vasilicht at gmail.com (Rodion Turlac)
Date: Sat Nov 22 22:38:42 2008
Subject: bluesoleil dongle and "ubt0 - Control request failed"
In-Reply-To: <23295d220811221242u51d04fd9hcc46ce7536a39cd1@mail.gmail.com>
References: <23295d220811181100y46748247l4572300c101087d7@mail.gmail.com>
	<bb4a86c70811191011v3fff4923m96924b511bc4c088@mail.gmail.com>
	<23295d220811221242u51d04fd9hcc46ce7536a39cd1@mail.gmail.com>
Message-ID: <23295d220811222238s6893cfabi4a9721a97f027902@mail.gmail.com>

2008/11/19 Maksim Yevmenkin <maksim.yevmenkin@gmail.com>:
> Hi,
>

Thanks for response.

> is  device's bd_addr really 11:11:11:11:11:11 or you just changed it?

Yes, it is.

> this particular dongle known to be a bit weird. please search for
> ISSCBTA in freebsd list archives.

I found several topics. This one is interesting
http://www.mail-archive.com/freebsd-bluetooth@freebsd.org/msg00074.html

>
> it also could be a problem with short control usb transfers, esp. on
> ehci controllers. so my suggestions are
>
> - try to plug the device in different ports if there is an external
> usb hub - try without it

I tried all ports those I have, but without success.

>
> - try to comment 'reset' command in /etc/rc.d/bluetooth

I had done this already.
>
> - play w/bios settings (anything related to usb2.0 if you have
> anything like that)

Also I did, nothing happened.

I think to test this dongle on FreeBSD 8 or on other motherboard.

Thanks again, Maksim
From vasilicht at gmail.com  Mon Nov 24 11:15:06 2008
From: vasilicht at gmail.com (Rodion Turlac)
Date: Mon Nov 24 11:15:18 2008
Subject: bluesoleil dongle and "ubt0 - Control request failed"
In-Reply-To: <bb4a86c70811191011v3fff4923m96924b511bc4c088@mail.gmail.com>
References: <23295d220811181100y46748247l4572300c101087d7@mail.gmail.com>
	<bb4a86c70811191011v3fff4923m96924b511bc4c088@mail.gmail.com>
Message-ID: <23295d220811241115o70280972r95f50ab5886c52c8@mail.gmail.com>

19.11.2008 20:11, Maksim Yevmenkin wrote:
>
> this particular dongle known to be a bit weird. please search for
> ISSCBTA in freebsd list archives.
>
> it also could be a problem with short control usb transfers, esp. on
> ehci controllers. so my suggestions are
I tested dongle under NetBSD 4.0 and it works fine
#btconfig
ubt0: bdaddr 11:11:11:11:11:11 flags 0x3<UP,RUNNING>

#btconfig ubt0 inquiry
Device Discovery from device: ubt0 .... 1 response
  1: bdaddr 00:1f:00:7d:bc:4a
   : name "Vasilich"
   : class: [0x5a0204] Cellular Phone <Networking> <Capturing> <Object Transfer>
        <Telephony>
   : page scan rep mode 0x01
   : page scan period mode 0x02
   : page scan mode 0x00
   : clock offset 11690
From maksim.yevmenkin at gmail.com  Mon Nov 24 11:26:21 2008
From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin)
Date: Mon Nov 24 11:26:27 2008
Subject: bluesoleil dongle and "ubt0 - Control request failed"
In-Reply-To: <23295d220811241115o70280972r95f50ab5886c52c8@mail.gmail.com>
References: <23295d220811181100y46748247l4572300c101087d7@mail.gmail.com>
	<bb4a86c70811191011v3fff4923m96924b511bc4c088@mail.gmail.com>
	<23295d220811241115o70280972r95f50ab5886c52c8@mail.gmail.com>
Message-ID: <bb4a86c70811241126l4edbce07m648b7c34023d969@mail.gmail.com>

On Mon, Nov 24, 2008 at 11:15 AM, Rodion Turlac <vasilicht@gmail.com> wrote:
> 19.11.2008 20:11, Maksim Yevmenkin wrote:
>>
>> this particular dongle known to be a bit weird. please search for
>> ISSCBTA in freebsd list archives.
>>
>> it also could be a problem with short control usb transfers, esp. on
>> ehci controllers. so my suggestions are
> I tested dongle under NetBSD 4.0 and it works fine
> #btconfig
> ubt0: bdaddr 11:11:11:11:11:11 flags 0x3<UP,RUNNING>
>
> #btconfig ubt0 inquiry
> Device Discovery from device: ubt0 .... 1 response
>  1: bdaddr 00:1f:00:7d:bc:4a
>   : name "Vasilich"
>   : class: [0x5a0204] Cellular Phone <Networking> <Capturing> <Object Transfer>
>        <Telephony>
>   : page scan rep mode 0x01
>   : page scan period mode 0x02
>   : page scan mode 0x00
>   : clock offset 11690

bluetooth device driver in netbsd and freebsd are somewhat similar. it
must be something in usb stack that prevents this device from working
normally.

thanks,
max