From owner-freebsd-bluetooth@FreeBSD.ORG Tue Nov 4 11:19:49 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EA211065670 for ; Tue, 4 Nov 2008 11:19:49 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id E86658FC23 for ; Tue, 4 Nov 2008 11:19:48 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 80C23130C39; Tue, 4 Nov 2008 12:19:47 +0100 (CET) Date: Tue, 4 Nov 2008 12:19:47 +0100 From: Guido Falsi To: freebsd-bluetooth@freebsd.org Message-ID: <20081104111947.GB62907@megatron.madpilot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 7.1-PRERELEASE User-Agent: Mutt/1.5.18 (2008-05-17) Subject: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 11:19:49 -0000 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 " 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 From owner-freebsd-bluetooth@FreeBSD.ORG Tue Nov 4 11:46:17 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8448C1065674 for ; Tue, 4 Nov 2008 11:46:17 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id 221418FC2A for ; Tue, 4 Nov 2008 11:46:16 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1KxKMO-00009o-8J; Tue, 04 Nov 2008 11:46:12 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00579-02; Tue, 4 Nov 2008 11:46:11 +0000 (GMT) Received: from [10.34.38.6] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1KxKML-00009k-4C; Tue, 04 Nov 2008 11:46:11 +0000 Received: (nullmailer pid 1128 invoked by uid 1000); Tue, 04 Nov 2008 11:45:05 -0000 Date: Tue, 4 Nov 2008 11:45:05 +0000 (GMT) To: Guido Falsi In-Reply-To: <20081104111947.GB62907@megatron.madpilot.net> References: <20081104111947.GB62907@megatron.madpilot.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1225799105.807983.1164.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 11:46:17 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Tue Nov 4 13:51:08 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEEF31065686 for ; Tue, 4 Nov 2008 13:51:08 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 0BFF18FC22 for ; Tue, 4 Nov 2008 13:51:07 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 161CB130C39; Tue, 4 Nov 2008 14:51:07 +0100 (CET) Date: Tue, 4 Nov 2008 14:51:07 +0100 From: Guido Falsi To: Iain Hibbert Message-ID: <20081104135107.GA64776@megatron.madpilot.net> References: <20081104111947.GB62907@megatron.madpilot.net> <1225799105.807983.1164.nullmailer@galant.ukfsn.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <1225799105.807983.1164.nullmailer@galant.ukfsn.org> X-Operating-System: FreeBSD 7.1-PRERELEASE User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 13:51:08 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sdpcontrol.txt" 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 --+HP7ph2BbKc20aGI-- From owner-freebsd-bluetooth@FreeBSD.ORG Tue Nov 4 18:06:09 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7D63106564A for ; Tue, 4 Nov 2008 18:06:09 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id E72298FC12 for ; Tue, 4 Nov 2008 18:06:07 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1KxQHw-0005Pj-OG; Tue, 04 Nov 2008 18:06:00 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20700-04; Tue, 4 Nov 2008 18:06:00 +0000 (GMT) Received: from [10.36.9.3] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1KxQHq-0005Pe-TE; Tue, 04 Nov 2008 18:06:00 +0000 Received: (nullmailer pid 644 invoked by uid 1000); Tue, 04 Nov 2008 17:54:24 -0000 Date: Tue, 4 Nov 2008 17:54:23 +0000 (GMT) To: Guido Falsi 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1225821264.107584.759.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 18:06:09 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Tue Nov 4 18:17:03 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00D491065674 for ; Tue, 4 Nov 2008 18:17:03 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0688FC12 for ; Tue, 4 Nov 2008 18:17:02 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by an-out-0708.google.com with SMTP id b6so292481ana.13 for ; Tue, 04 Nov 2008 10:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=iulsuCIwuxpTyase2yj/3NUo9z85BBa8t/LqtqC5HAI=; b=ITorvHHeFGssNt8DQ4Qd34RFv8jC8YOf26XV5sWrXXF1R86M01MLgMUWByXw4wB8ql yyYQPvekx8v57OjIKMI0vrGEkDWKXhvdy/zEpDAExp6FxtKufCbABoKddAq9qGxebq54 U43hzHlcISCWoFY49/2j4ssv3eYY3QLYjUqzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=WffxaPysb0fjb3e7IywG/SydpEax7M4CqoIOliAf4rGk4EXXrU0DDaFfR7Y/VGYyUX 8tnpy4a6GlarHbLFFu+vVkENI0tKA5VdDMLousEamCglo9THzeiXn5OKLjukwLdr/57q Qn+1vPt2AbCLvVxlxZxg/CIOEqgg7DgN31WAE= Received: by 10.86.62.3 with SMTP id k3mr15430fga.6.1225822620446; Tue, 04 Nov 2008 10:17:00 -0800 (PST) Received: by 10.86.9.3 with HTTP; Tue, 4 Nov 2008 10:17:00 -0800 (PST) Message-ID: Date: Tue, 4 Nov 2008 11:17:00 -0700 From: "Maksim Yevmenkin" To: "Guido Falsi" In-Reply-To: <1225821264.107584.759.nullmailer@galant.ukfsn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 18:17:03 -0000 On 11/4/08, Iain Hibbert 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 owner-freebsd-bluetooth@FreeBSD.ORG Tue Nov 4 19:17:53 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DBA51065672 for ; Tue, 4 Nov 2008 19:17:53 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id CA79E8FC26 for ; Tue, 4 Nov 2008 19:17:52 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.localdomain with esmtp (Exim 4.50) id 1KxRPQ-0004tu-Dx; Tue, 04 Nov 2008 19:17:48 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18611-05; Tue, 4 Nov 2008 19:17:47 +0000 (GMT) Received: from [10.35.25.95] (helo=rya-online.net) by localhost.localdomain with smtp (Exim 4.50) id 1KxRPI-0004tl-K7; Tue, 04 Nov 2008 19:17:47 +0000 Received: (nullmailer pid 1222 invoked by uid 1000); Tue, 04 Nov 2008 19:16:07 -0000 Date: Tue, 4 Nov 2008 19:16:07 +0000 (GMT) To: Maksim Yevmenkin In-Reply-To: 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> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1376276759-1225825929=:881" Content-ID: Message-Id: <1225826167.716196.1082.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.localdomain); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 19:17:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1376276759-1225825929=:881 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: 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 --0-1376276759-1225825929=:881 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=hcidump.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: connecting to Nokia PC Suite serial port service Content-Disposition: ATTACHMENT; FILENAME=hcidump.txt SENJIHNuaWZmZXIgLSBCbHVldG9vdGggcGFja2V0IGFuYWx5emVyIHZlciAx LjQyLW5ldGJ0DQo8IEhDSSBDb21tYW5kOiBDcmVhdGUgQ29ubmVjdGlvbiAo MHgwMXwweDAwMDUpIHBsZW4gMTMNCiAgICBiZGFkZHIgMDA6MTY6QkM6Kjoq OiogcHR5cGUgMHhjYzE4IHJzd2l0Y2ggMHgwMSBjbGtvZmZzZXQgMHgwNmE5 DQogICAgUGFja2V0IHR5cGU6IERNMSBETTMgRE01IERIMSBESDMgREg1IA0K PiBIQ0kgRXZlbnQ6IENvbW1hbmQgU3RhdHVzICgweDBmKSBwbGVuIDQNCiAg ICBDcmVhdGUgQ29ubmVjdGlvbiAoMHgwMXwweDAwMDUpIHN0YXR1cyAweDAw IG5jbWQgMQ0KPiBIQ0kgRXZlbnQ6IENvbm5lY3QgQ29tcGxldGUgKDB4MDMp IHBsZW4gMTENCiAgICBzdGF0dXMgMHgwMCBoYW5kbGUgNDUgYmRhZGRyIDAw OjE2OkJDOio6KjoqIHR5cGUgQUNMIGVuY3J5cHQgMHgwMA0KPCBIQ0kgQ29t bWFuZDogV3JpdGUgTGluayBQb2xpY3kgU2V0dGluZ3MgKDB4MDJ8MHgwMDBk KSBwbGVuIDQNCiAgICBoYW5kbGUgNDUgcG9saWN5IDB4MDcNCiAgICBMaW5r IHBvbGljeTogUlNXSVRDSCBIT0xEIFNOSUZGIA0KPCBBQ0wgZGF0YTogaGFu ZGxlIDQ1IGZsYWdzIDB4MDIgZGxlbiAxMg0KICAgIEwyQ0FQKHMpOiBDb25u ZWN0IHJlcTogcHNtIDMgc2NpZCAweDAwNDINCj4gSENJIEV2ZW50OiBOdW1i ZXIgb2YgQ29tcGxldGVkIFBhY2tldHMgKDB4MTMpIHBsZW4gNQ0KICAgIGhh bmRsZSA0NSBwYWNrZXRzIDENCj4gSENJIEV2ZW50OiBDb21tYW5kIENvbXBs ZXRlICgweDBlKSBwbGVuIDYNCiAgICBXcml0ZSBMaW5rIFBvbGljeSBTZXR0 aW5ncyAoMHgwMnwweDAwMGQpIG5jbWQgMQ0KICAgIHN0YXR1cyAweDAwIGhh bmRsZSA0NQ0KPCBIQ0kgQ29tbWFuZDogUmVhZCBDbG9jayBPZmZzZXQgKDB4 MDF8MHgwMDFmKSBwbGVuIDINCiAgICBoYW5kbGUgNDUNCj4gSENJIEV2ZW50 OiBQYWdlIFNjYW4gUmVwZXRpdGlvbiBNb2RlIENoYW5nZSAoMHgyMCkgcGxl biA3DQogICAgYmRhZGRyIDAwOjE2OkJDOio6KjoqIG1vZGUgMQ0KPiBIQ0kg RXZlbnQ6IE1heCBTbG90cyBDaGFuZ2UgKDB4MWIpIHBsZW4gMw0KICAgIGhh bmRsZSA0NSBzbG90cyA1DQo+IEhDSSBFdmVudDogQ29tbWFuZCBTdGF0dXMg KDB4MGYpIHBsZW4gNA0KICAgIFJlYWQgQ2xvY2sgT2Zmc2V0ICgweDAxfDB4 MDAxZikgc3RhdHVzIDB4MDAgbmNtZCAwDQo+IEhDSSBFdmVudDogQ29tbWFu ZCBTdGF0dXMgKDB4MGYpIHBsZW4gNA0KICAgIFVua25vd24gKDB4MDB8MHgw MDAwKSBzdGF0dXMgMHgwMCBuY21kIDENCj4gSENJIEV2ZW50OiBSZWFkIENs b2NrIE9mZnNldCBDb21wbGV0ZSAoMHgxYykgcGxlbiA1DQogICAgc3RhdHVz IDB4MDAgaGFuZGxlIDQ1IGNsa29mZnNldCAweDA2YTENCj4gQUNMIGRhdGE6 IGhhbmRsZSA0NSBmbGFncyAweDAyIGRsZW4gMTYNCiAgICBMMkNBUChzKTog Q29ubmVjdCByc3A6IGRjaWQgMHgwMDQwIHNjaWQgMHgwMDQyIHJlc3VsdCAw IHN0YXR1cyAwDQogICAgICBDb25uZWN0aW9uIHN1Y2Nlc3NmdWwNCjwgQUNM IGRhdGE6IGhhbmRsZSA0NSBmbGFncyAweDAyIGRsZW4gMTINCiAgICBMMkNB UChzKTogQ29uZmlnIHJlcTogZGNpZCAweDAwNDAgZmxhZ3MgMHgwMCBjbGVu IDANCj4gQUNMIGRhdGE6IGhhbmRsZSA0NSBmbGFncyAweDAyIGRsZW4gMTYN CiAgICBMMkNBUChzKTogQ29uZmlnIHJlcTogZGNpZCAweDAwNDIgZmxhZ3Mg MHgwMCBjbGVuIDQNCiAgICAgIE1UVSAzMjc3MiANCjwgQUNMIGRhdGE6IGhh bmRsZSA0NSBmbGFncyAweDAyIGRsZW4gMTQNCiAgICBMMkNBUChzKTogQ29u ZmlnIHJzcDogc2NpZCAweDAwNDAgZmxhZ3MgMHgwMCByZXN1bHQgMCBjbGVu IDANCiAgICAgIFN1Y2Nlc3MNCj4gSENJIEV2ZW50OiBOdW1iZXIgb2YgQ29t cGxldGVkIFBhY2tldHMgKDB4MTMpIHBsZW4gNQ0KICAgIGhhbmRsZSA0NSBw YWNrZXRzIDENCj4gSENJIEV2ZW50OiBOdW1iZXIgb2YgQ29tcGxldGVkIFBh Y2tldHMgKDB4MTMpIHBsZW4gNQ0KICAgIGhhbmRsZSA0NSBwYWNrZXRzIDEN Cj4gQUNMIGRhdGE6IGhhbmRsZSA0NSBmbGFncyAweDAyIGRsZW4gMTQNCiAg ICBMMkNBUChzKTogQ29uZmlnIHJzcDogc2NpZCAweDAwNDIgZmxhZ3MgMHgw MCByZXN1bHQgMCBjbGVuIDANCiAgICAgIFN1Y2Nlc3MNCjwgQUNMIGRhdGE6 IGhhbmRsZSA0NSBmbGFncyAweDAyIGRsZW4gOA0KICAgIEwyQ0FQKGQpOiBj aWQgMHgwMDQwIGxlbiA0IFtwc20gM10NCiAgICAgIFJGQ09NTShzKTogU0FC TTogY3IgMSBkbGNpIDAgcGYgMSBpbGVuIDAgZmNzIDB4MWMgDQo+IEhDSSBF dmVudDogTnVtYmVyIG9mIENvbXBsZXRlZCBQYWNrZXRzICgweDEzKSBwbGVu IDUNCiAgICBoYW5kbGUgNDUgcGFja2V0cyAxDQo+IEFDTCBkYXRhOiBoYW5k bGUgNDUgZmxhZ3MgMHgwMiBkbGVuIDgNCiAgICBMMkNBUChkKTogY2lkIDB4 MDA0MiBsZW4gNCBbcHNtIDNdDQogICAgICBSRkNPTU0ocyk6IFVBOiBjciAx IGRsY2kgMCBwZiAxIGlsZW4gMCBmY3MgMHhkNyANCjwgQUNMIGRhdGE6IGhh bmRsZSA0NSBmbGFncyAweDAyIGRsZW4gMTgNCiAgICBMMkNBUChkKTogY2lk IDB4MDA0MCBsZW4gMTQgW3BzbSAzXQ0KICAgICAgUkZDT01NKHMpOiBQTiBD TUQ6IGNyIDEgZGxjaSAwIHBmIDAgaWxlbiAxMCBmY3MgMHg3MCBtY2NfbGVu IDgNCiAgICAgIGRsY2kgMzAgZnJhbWVfdHlwZSAwIGNyZWRpdF9mbG93IDE1 IHByaSAzMSBhY2tfdGltZXIgMA0KICAgICAgZnJhbWVfc2l6ZSAxMjcgbWF4 X3JldHJhbnMgMCBjcmVkaXRzIDcNCj4gSENJIEV2ZW50OiBOdW1iZXIgb2Yg Q29tcGxldGVkIFBhY2tldHMgKDB4MTMpIHBsZW4gNQ0KICAgIGhhbmRsZSA0 NSBwYWNrZXRzIDENCj4gQUNMIGRhdGE6IGhhbmRsZSA0NSBmbGFncyAweDAy IGRsZW4gMTgNCiAgICBMMkNBUChkKTogY2lkIDB4MDA0MiBsZW4gMTQgW3Bz bSAzXQ0KICAgICAgUkZDT01NKHMpOiBQTiBSU1A6IGNyIDAgZGxjaSAwIHBm IDAgaWxlbiAxMCBmY3MgMHhhYSBtY2NfbGVuIDgNCiAgICAgIGRsY2kgMzAg ZnJhbWVfdHlwZSAwIGNyZWRpdF9mbG93IDE0IHByaSAzMSBhY2tfdGltZXIg MA0KICAgICAgZnJhbWVfc2l6ZSAxMjcgbWF4X3JldHJhbnMgMCBjcmVkaXRz IDANCjwgQUNMIGRhdGE6IGhhbmRsZSA0NSBmbGFncyAweDAyIGRsZW4gOA0K ICAgIEwyQ0FQKGQpOiBjaWQgMHgwMDQwIGxlbiA0IFtwc20gM10NCiAgICAg IFJGQ09NTShzKTogU0FCTTogY3IgMSBkbGNpIDMwIHBmIDEgaWxlbiAwIGZj cyAweDZkIA0KPiBIQ0kgRXZlbnQ6IE51bWJlciBvZiBDb21wbGV0ZWQgUGFj a2V0cyAoMHgxMykgcGxlbiA1DQogICAgaGFuZGxlIDQ1IHBhY2tldHMgMQ0K PiBIQ0kgRXZlbnQ6IExpbmsgS2V5IFJlcXVlc3QgKDB4MTcpIHBsZW4gNg0K ICAgIGJkYWRkciAwMDoxNjpCQzoqOio6Kg0KPCBIQ0kgQ29tbWFuZDogTGlu ayBLZXkgUmVxdWVzdCBSZXBseSAoMHgwMXwweDAwMGIpIHBsZW4gMjINCiAg ICBiZGFkZHIgMDA6MTY6QkM6KjoqOioga2V5ICoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQo+IEhDSSBFdmVudDogQ29tbWFuZCBDb21wbGV0 ZSAoMHgwZSkgcGxlbiAxMA0KICAgIExpbmsgS2V5IFJlcXVlc3QgUmVwbHkg KDB4MDF8MHgwMDBiKSBuY21kIDENCiAgICBzdGF0dXMgMHgwMCBiZGFkZHIg MDA6MTY6QkM6KjoqOioNCj4gSENJIEV2ZW50OiBFbmNyeXB0IENoYW5nZSAo MHgwOCkgcGxlbiA0DQogICAgc3RhdHVzIDB4MDAgaGFuZGxlIDQ1IGVuY3J5 cHQgMHgwMQ0KPiBBQ0wgZGF0YTogaGFuZGxlIDQ1IGZsYWdzIDB4MDIgZGxl biA4DQogICAgTDJDQVAoZCk6IGNpZCAweDAwNDIgbGVuIDQgW3BzbSAzXQ0K ICAgICAgUkZDT01NKHMpOiBVQTogY3IgMSBkbGNpIDMwIHBmIDEgaWxlbiAw IGZjcyAweGE2IA0KPCBBQ0wgZGF0YTogaGFuZGxlIDQ1IGZsYWdzIDB4MDIg ZGxlbiAxMw0KICAgIEwyQ0FQKGQpOiBjaWQgMHgwMDQwIGxlbiA5IFtwc20g M10NCiAgICAgIFJGQ09NTShzKTogTVNDIENNRDogY3IgMSBkbGNpIDAgcGYg MCBpbGVuIDUgZmNzIDB4NzAgbWNjX2xlbiAzDQogICAgICBkbGNpIDMwIGZj IDAgcnRjIDEgcnRyIDEgaWMgMCBkdiAxIGIxIDEgYjIgMCBiMyAwIGxlbiAx DQo+IEFDTCBkYXRhOiBoYW5kbGUgNDUgZmxhZ3MgMHgwMiBkbGVuIDEyDQog ICAgTDJDQVAoZCk6IGNpZCAweDAwNDIgbGVuIDggW3BzbSAzXQ0KICAgICAg UkZDT01NKHMpOiBNU0MgQ01EOiBjciAwIGRsY2kgMCBwZiAwIGlsZW4gNCBm Y3MgMHhhYSBtY2NfbGVuIDINCiAgICAgIGRsY2kgMzAgZmMgMCBydGMgMSBy dHIgMSBpYyAwIGR2IDAgYjEgMSBiMiAwIGIzIDAgbGVuIDENCj4gSENJIEV2 ZW50OiBOdW1iZXIgb2YgQ29tcGxldGVkIFBhY2tldHMgKDB4MTMpIHBsZW4g NQ0KICAgIGhhbmRsZSA0NSBwYWNrZXRzIDENCjwgQUNMIGRhdGE6IGhhbmRs ZSA0NSBmbGFncyAweDAyIGRsZW4gMTINCiAgICBMMkNBUChkKTogY2lkIDB4 MDA0MCBsZW4gOCBbcHNtIDNdDQogICAgICBSRkNPTU0ocyk6IE1TQyBSU1A6 IGNyIDEgZGxjaSAwIHBmIDAgaWxlbiA0IGZjcyAweDcwIG1jY19sZW4gMg0K ICAgICAgZGxjaSAzMCBmYyAwIHJ0YyAxIHJ0ciAxIGljIDAgZHYgMCBiMSAx IGIyIDAgYjMgMCBsZW4gMQ0KPiBBQ0wgZGF0YTogaGFuZGxlIDQ1IGZsYWdz IDB4MDIgZGxlbiA5DQogICAgTDJDQVAoZCk6IGNpZCAweDAwNDIgbGVuIDUg W3BzbSAzXQ0KICAgICAgUkZDT01NKGQpOiBVSUg6IGNyIDAgZGxjaSAzMCBw ZiAxIGlsZW4gMCBmY3MgMHgzNyBjcmVkaXRzIDEwDQo+IEFDTCBkYXRhOiBo YW5kbGUgNDUgZmxhZ3MgMHgwMiBkbGVuIDEyDQogICAgTDJDQVAoZCk6IGNp ZCAweDAwNDIgbGVuIDggW3BzbSAzXQ0KICAgICAgUkZDT01NKHMpOiBNU0Mg UlNQOiBjciAwIGRsY2kgMCBwZiAwIGlsZW4gNCBmY3MgMHhhYSBtY2NfbGVu IDINCiAgICAgIGRsY2kgMzAgZmMgMCBydGMgMSBydHIgMSBpYyAwIGR2IDEg YjEgMSBiMiAwIGIzIDAgbGVuIDENCj4gSENJIEV2ZW50OiBOdW1iZXIgb2Yg Q29tcGxldGVkIFBhY2tldHMgKDB4MTMpIHBsZW4gNQ0KICAgIGhhbmRsZSA0 NSBwYWNrZXRzIDENCjwgQUNMIGRhdGE6IGhhbmRsZSA0NSBmbGFncyAweDAy IGRsZW4gMTANCiAgICBMMkNBUChkKTogY2lkIDB4MDA0MCBsZW4gNiBbcHNt IDNdDQogICAgICBSRkNPTU0oZCk6IFVJSDogY3IgMSBkbGNpIDMwIHBmIDEg aWxlbiAxIGZjcyAweGVkIGNyZWRpdHMgMjUNCiAgICAgIDBEIA0KPiBIQ0kg RXZlbnQ6IE51bWJlciBvZiBDb21wbGV0ZWQgUGFja2V0cyAoMHgxMykgcGxl biA1DQogICAgaGFuZGxlIDQ1IHBhY2tldHMgMQ0KPiBBQ0wgZGF0YTogaGFu ZGxlIDQ1IGZsYWdzIDB4MDIgZGxlbiA4DQogICAgTDJDQVAoZCk6IGNpZCAw eDAwNDIgbGVuIDQgW3BzbSAzXQ0KICAgICAgUkZDT01NKHMpOiBESVNDOiBj ciAwIGRsY2kgMzAgcGYgMSBpbGVuIDAgZmNzIDB4ZWQgDQo8IEFDTCBkYXRh OiBoYW5kbGUgNDUgZmxhZ3MgMHgwMiBkbGVuIDgNCiAgICBMMkNBUChkKTog Y2lkIDB4MDA0MCBsZW4gNCBbcHNtIDNdDQogICAgICBSRkNPTU0ocyk6IFVB OiBjciAwIGRsY2kgMzAgcGYgMSBpbGVuIDAgZmNzIDB4YzcgDQo+IEhDSSBF dmVudDogTnVtYmVyIG9mIENvbXBsZXRlZCBQYWNrZXRzICgweDEzKSBwbGVu IDUNCiAgICBoYW5kbGUgNDUgcGFja2V0cyAxDQo+IEFDTCBkYXRhOiBoYW5k bGUgNDUgZmxhZ3MgMHgwMiBkbGVuIDgNCiAgICBMMkNBUChkKTogY2lkIDB4 MDA0MiBsZW4gNCBbcHNtIDNdDQogICAgICBSRkNPTU0ocyk6IERJU0M6IGNy IDAgZGxjaSAwIHBmIDEgaWxlbiAwIGZjcyAweDljIA0KPCBBQ0wgZGF0YTog aGFuZGxlIDQ1IGZsYWdzIDB4MDIgZGxlbiA4DQogICAgTDJDQVAoZCk6IGNp ZCAweDAwNDAgbGVuIDQgW3BzbSAzXQ0KICAgICAgUkZDT01NKHMpOiBVQTog Y3IgMCBkbGNpIDAgcGYgMSBpbGVuIDAgZmNzIDB4YjYgDQo+IEhDSSBFdmVu dDogTnVtYmVyIG9mIENvbXBsZXRlZCBQYWNrZXRzICgweDEzKSBwbGVuIDUN CiAgICBoYW5kbGUgNDUgcGFja2V0cyAxDQo8IEFDTCBkYXRhOiBoYW5kbGUg NDUgZmxhZ3MgMHgwMiBkbGVuIDEyDQogICAgTDJDQVAocyk6IERpc2Nvbm4g cmVxOiBkY2lkIDB4MDA0MCBzY2lkIDB4MDA0Mg0KPiBBQ0wgZGF0YTogaGFu ZGxlIDQ1IGZsYWdzIDB4MDIgZGxlbiAxMg0KICAgIEwyQ0FQKHMpOiBEaXNj b25uIHJlcTogZGNpZCAweDAwNDIgc2NpZCAweDAwNDANCjwgQUNMIGRhdGE6 IGhhbmRsZSA0NSBmbGFncyAweDAyIGRsZW4gMTINCiAgICBMMkNBUChzKTog RGlzY29ubiByc3A6IGRjaWQgMHgwMDQyIHNjaWQgMHgwMDQwDQo+IEhDSSBF dmVudDogTnVtYmVyIG9mIENvbXBsZXRlZCBQYWNrZXRzICgweDEzKSBwbGVu IDUNCiAgICBoYW5kbGUgNDUgcGFja2V0cyAxDQo+IEhDSSBFdmVudDogTnVt YmVyIG9mIENvbXBsZXRlZCBQYWNrZXRzICgweDEzKSBwbGVuIDUNCiAgICBo YW5kbGUgNDUgcGFja2V0cyAxDQo+IEFDTCBkYXRhOiBoYW5kbGUgNDUgZmxh Z3MgMHgwMiBkbGVuIDEyDQogICAgTDJDQVAocyk6IERpc2Nvbm4gcnNwOiBk Y2lkIDB4MDA0MCBzY2lkIDB4MDA0Mg0KPCBIQ0kgQ29tbWFuZDogRGlzY29u bmVjdCAoMHgwMXwweDAwMDYpIHBsZW4gMw0KICAgIGhhbmRsZSA0NSByZWFz b24gMHgxMw0KICAgIFJlYXNvbjogUmVtb3RlIFVzZXIgVGVybWluYXRlZCBD b25uZWN0aW9uDQo+IEhDSSBFdmVudDogQ29tbWFuZCBTdGF0dXMgKDB4MGYp IHBsZW4gNA0KICAgIERpc2Nvbm5lY3QgKDB4MDF8MHgwMDA2KSBzdGF0dXMg MHgwMCBuY21kIDENCj4gSENJIEV2ZW50OiBEaXNjb25uIENvbXBsZXRlICgw eDA1KSBwbGVuIDQNCiAgICBzdGF0dXMgMHgwMCBoYW5kbGUgNDUgcmVhc29u IDB4MTYNCiAgICBSZWFzb246IENvbm5lY3Rpb24gVGVybWluYXRlZCBieSBM b2NhbCBIb3N0DQo= --0-1376276759-1225825929=:881-- From owner-freebsd-bluetooth@FreeBSD.ORG Tue Nov 4 20:56:12 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B3D2106564A for ; Tue, 4 Nov 2008 20:56:12 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id BC5B48FC20 for ; Tue, 4 Nov 2008 20:56:11 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from localhost (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 3D6D7130C08; Tue, 4 Nov 2008 21:56:10 +0100 (CET) X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by localhost (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY3wCwBgIUzO; Tue, 4 Nov 2008 21:56:06 +0100 (CET) Received: from anakin.madpilot.net (anakin.madpilot.net [172.24.42.10]) by megatron.madpilot.net (Postfix) with ESMTP; Tue, 4 Nov 2008 21:56:06 +0100 (CET) Message-ID: <4910B6E6.7070206@madpilot.net> Date: Tue, 04 Nov 2008 21:56:06 +0100 From: Guido Falsi User-Agent: Thunderbird 2.0.0.17 (X11/20080927) MIME-Version: 1.0 To: Iain Hibbert 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> In-Reply-To: <1225821264.107584.759.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 20:56:12 -0000 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 From owner-freebsd-bluetooth@FreeBSD.ORG Tue Nov 4 22:20:11 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 696351065675 for ; Tue, 4 Nov 2008 22:20:11 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 13A798FC08 for ; Tue, 4 Nov 2008 22:20:11 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from localhost (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 54250130C08; Tue, 4 Nov 2008 23:20:10 +0100 (CET) X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by localhost (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLRlp2c81hQ9; Tue, 4 Nov 2008 23:20:08 +0100 (CET) Received: from anakin.madpilot.net (anakin.madpilot.net [172.24.42.10]) by megatron.madpilot.net (Postfix) with ESMTP; Tue, 4 Nov 2008 23:20:08 +0100 (CET) Message-ID: <4910CA97.6030708@madpilot.net> Date: Tue, 04 Nov 2008 23:20:07 +0100 From: Guido Falsi User-Agent: Thunderbird 2.0.0.17 (X11/20080927) MIME-Version: 1.0 To: Iain Hibbert 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> In-Reply-To: <4910B6E6.7070206@madpilot.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 22:20:11 -0000 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 From owner-freebsd-bluetooth@FreeBSD.ORG Wed Nov 5 07:25:29 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E03D1065670 for ; Wed, 5 Nov 2008 07:25:29 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 753DB8FC12 for ; Wed, 5 Nov 2008 07:25:29 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1KxcWw-0005YW-6j for freebsd-bluetooth@freebsd.org; Tue, 04 Nov 2008 23:10:18 -0800 Message-ID: <20337030.post@talk.nabble.com> Date: Tue, 4 Nov 2008 23:10:18 -0800 (PST) From: angelinalove To: freebsd-bluetooth@freebsd.org In-Reply-To: <20081104111947.GB62907@megatron.madpilot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: selena12321@gmail.com References: <20081104111947.GB62907@megatron.madpilot.net> Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2008 07:25:29 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Fri Nov 7 21:00:06 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 334FE1065672 for ; Fri, 7 Nov 2008 21:00:06 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id DA8A38FC22 for ; Fri, 7 Nov 2008 21:00:05 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1KyYQy-0003oy-EQ; Fri, 07 Nov 2008 21:00:00 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14620-03; Fri, 7 Nov 2008 21:00:00 +0000 (GMT) Received: from [10.199.59.87] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1KyYQv-0003on-Uf; Fri, 07 Nov 2008 21:00:00 +0000 Received: (nullmailer pid 659 invoked by uid 1000); Fri, 07 Nov 2008 20:58:41 -0000 Date: Fri, 7 Nov 2008 20:58:40 +0000 (GMT) To: Guido Falsi 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1226091521.039371.399.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2008 21:00:06 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Fri Nov 7 21:20:23 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5387B1065692 for ; Fri, 7 Nov 2008 21:20:23 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id E5AE18FC0A for ; Fri, 7 Nov 2008 21:20:22 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from localhost (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 23AD0130C08; Fri, 7 Nov 2008 22:20:22 +0100 (CET) X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by localhost (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jh3MVaTXUgdl; Fri, 7 Nov 2008 22:20:19 +0100 (CET) Received: from anakin.madpilot.net (anakin.madpilot.net [172.24.42.10]) by megatron.madpilot.net (Postfix) with ESMTP; Fri, 7 Nov 2008 22:20:19 +0100 (CET) Message-ID: <4914B113.60303@madpilot.net> Date: Fri, 07 Nov 2008 22:20:19 +0100 From: Guido Falsi User-Agent: Thunderbird 2.0.0.17 (X11/20080927) MIME-Version: 1.0 To: Iain Hibbert 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> In-Reply-To: <1226091521.039371.399.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2008 21:20:23 -0000 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 From owner-freebsd-bluetooth@FreeBSD.ORG Fri Nov 7 22:07:31 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38BFF106567A for ; Fri, 7 Nov 2008 22:07:31 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id B31DE8FC12 for ; Fri, 7 Nov 2008 22:07:30 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1139822fgb.35 for ; Fri, 07 Nov 2008 14:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=xIX7oo2FE7QvddFHZlOu16pOZRATs60ZrWBKPhgCd/Q=; b=Oh/Dg95xNzBua7LfwFRdXePzVg0744A60cfTBr+MTCQIxmAbBPFqbs7b7WcwDFrJmL F1OZOMD9xyw/akcbsALbH2wn9iM2dWav+LvlzKtY04+zD1cIbotUCJqaSCjNGjeynwvY y/0pZMDBB8kpBA3Uk/CLYIeZj4AoLRUe4huck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ZwM6w9O6qAUhHagRFf5OsUKLTyZnsYTVOWflXUsxdRhS3TfO0t49X7f4ZQqPWuyNRM k1Mo6co5/gG2usrcEboRIdagPWMBDpIWxt1LC2ZwHYjNj6jiE7tU6wBtCuzshH5YdeDH 1+RGC18/kxHpWO1I7Gc8wr0OHOV8q51VdXi70= Received: by 10.86.23.17 with SMTP id 17mr4473535fgw.0.1226095649531; Fri, 07 Nov 2008 14:07:29 -0800 (PST) Received: by 10.86.9.3 with HTTP; Fri, 7 Nov 2008 14:07:29 -0800 (PST) Message-ID: Date: Fri, 7 Nov 2008 14:07:29 -0800 From: "Maksim Yevmenkin" To: "Guido Falsi" In-Reply-To: <4914B113.60303@madpilot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2008 22:07:31 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Fri Nov 7 22:32:51 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E37E1065673 for ; Fri, 7 Nov 2008 22:32:51 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id F0B498FC19 for ; Fri, 7 Nov 2008 22:32:50 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1KyZsn-0004Sf-El; Fri, 07 Nov 2008 22:32:49 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16871-08; Fri, 7 Nov 2008 22:32:49 +0000 (GMT) Received: from [10.199.59.87] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1KyZsl-0004Sa-Vw; Fri, 07 Nov 2008 22:32:49 +0000 Received: (nullmailer pid 698 invoked by uid 1000); Fri, 07 Nov 2008 22:31:39 -0000 Date: Fri, 7 Nov 2008 22:31:39 +0000 (GMT) To: Guido Falsi 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1226097099.328979.788.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2008 22:32:51 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Sat Nov 8 01:03:12 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D0C9106567D for ; Sat, 8 Nov 2008 01:03:12 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id BE8988FC12 for ; Sat, 8 Nov 2008 01:03:11 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from localhost (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 29CF9130C08; Sat, 8 Nov 2008 02:03:10 +0100 (CET) X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by localhost (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWzWl5QTHyoo; Sat, 8 Nov 2008 02:03:07 +0100 (CET) Received: from wedge.madpilot.net (wedge.madpilot.net [172.24.42.11]) by megatron.madpilot.net (Postfix) with ESMTP; Sat, 8 Nov 2008 02:03:07 +0100 (CET) Message-ID: <4914E54B.4060206@madpilot.net> Date: Sat, 08 Nov 2008 02:03:07 +0100 From: Guido Falsi User-Agent: Thunderbird 2.0.0.17 (X11/20080927) MIME-Version: 1.0 To: Iain Hibbert 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> In-Reply-To: <1226097099.328979.788.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2008 01:03:12 -0000 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 From owner-freebsd-bluetooth@FreeBSD.ORG Sat Nov 8 09:17:24 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58D7E106567F for ; Sat, 8 Nov 2008 09:17:24 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id E68C08FC18 for ; Sat, 8 Nov 2008 09:17:23 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1KyjwV-0007ct-9h; Sat, 08 Nov 2008 09:17:19 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29061-06; Sat, 8 Nov 2008 09:17:18 +0000 (GMT) Received: from [10.34.38.217] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1KyjwT-0007co-0x; Sat, 08 Nov 2008 09:17:18 +0000 Received: (nullmailer pid 479 invoked by uid 1000); Sat, 08 Nov 2008 09:16:09 -0000 Date: Sat, 8 Nov 2008 09:16:09 +0000 (GMT) To: Guido Falsi 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1226135769.665964.502.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2008 09:17:24 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Sat Nov 8 12:20:50 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98B1C106564A for ; Sat, 8 Nov 2008 12:20:50 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 319378FC08 for ; Sat, 8 Nov 2008 12:20:50 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from localhost (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id D2432130C08; Sat, 8 Nov 2008 13:20:48 +0100 (CET) X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by localhost (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUI2O8eNrySC; Sat, 8 Nov 2008 13:20:45 +0100 (CET) Received: from anakin.madpilot.net (anakin.madpilot.net [172.24.42.10]) by megatron.madpilot.net (Postfix) with ESMTP; Sat, 8 Nov 2008 13:20:45 +0100 (CET) Message-ID: <4915841D.1060503@madpilot.net> Date: Sat, 08 Nov 2008 13:20:45 +0100 From: Guido Falsi User-Agent: Thunderbird 2.0.0.17 (X11/20080927) MIME-Version: 1.0 To: Iain Hibbert 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> In-Reply-To: <1226135769.665964.502.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2008 12:20:50 -0000 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