|

»

freebsd-bluetooth

RFComm behaviour with nokia mobiles

View: New views

16 Messages — Rating Filter: Alert me

	RFComm behaviour with nokia mobiles by Guido Falsi :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by Iain Hibbert :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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); _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by Guido Falsi :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> 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 _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by Iain Hibbert :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by Maksim Yevmenkin-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On 11/4/08, Iain Hibbert <plunky@...> 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 _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by Iain Hibbert :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 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 _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by Guido Falsi :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by Guido Falsi :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by angelinalove :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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.
	Re: RFComm behaviour with nokia mobiles by Iain Hibbert :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by Guido Falsi :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by Maksim Yevmenkin-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by Iain Hibbert :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by Guido Falsi :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by Iain Hibbert :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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? _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."
	Re: RFComm behaviour with nokia mobiles by Guido Falsi :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> _______________________________________________ freebsd-bluetooth@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."