March 2012 - Bluetooth-dev - lists.apple.com

Re: Using unsecure/unauthenticated RFCOMM
by Matt Gillette 02 Mar '12

02 Mar '12

> This can be done … programmatically with BluetoothHCIWriteSimplePairingMode. Do not do this in released code. Bluetooth Explorer has this for debugging purposes only. BluetoothHCIWriteSimplePairingMode is private API that causes changes beyond your app and should not be used in released code. Simple Secure Pairing requires that all L2CAP connections be authenticated (SDP excluded). Matt On Mar 1, 2012, at 11:06 PM, ghazel(a)gmail.com wrote: > One thing I forgot to mention which is crucial for OS X since about > 10.5.8. To avoid the pairing dialog when forming an outgoing > connection, "Simple Pairing" must also be disabled. This can be done > in Bluetooth Explorer or programmatically with > BluetoothHCIWriteSimplePairingMode. Normally this switches out the > number-confirmation style pairing for typed digits, but with > authorization off and simple pairing off no dialog appears. > > -Greg > > On Mon, Feb 27, 2012 at 12:21 PM, Greg Hazel <ghazel(a)gmail.com> wrote: >> Hi, >> >> I don't find it to be true that the Windows stack requires authentication. I have successfully connected pairs of authenticated devices on Windows using SO_BTH_AUTHENTICATE set to false and on bluez using RFCOMM_LM_AUTH set to false. Be sure that both the connecting socket and the listening socket have these set. Using those and openConnection on OS X with authenticationRequired:NO, I am able to form unauthenticated RFCOMM connections initiated by OS X. It seems that OS X has a limitation, or at least an oversight from the API I can find, which prevents it from listening for unauthenticated RFCOMM connections. >> >> I was actually hoping someone on this list knew a way to get OS X to not require authentication for incoming RFCOMM channels, since other platforms seem to support it. >> >> -Greg >> >> On Feb 27, 2012, at 5:11 AM, Matthias Ringwald wrote: >> >>> Hi >>> >>> I would assume that at least one of your devices insists on an authorized RFCOMM connection, which is at least true for Windows MS stack. >>> >>> It makes sense to allow unencrypted baseband connections - by this, you can do SDP queries and learn about the remote device before setting up an encrypted connection for the actual data. >>> >>> Best >>> Matthias >>> >>> On Feb 23, 2012, at 7:09 PM, Alexei Czeskis wrote: >>> >>>> Hello! >>>> >>>> Does anyone have any experience using unsecure/unauthenticated RFCOMM >>>> on OS X? I'm trying to do unsecure RFCOMM between two unpaired >>>> bluetooth devices (one is a MacBook running 10.7.3, the other is an >>>> Android phone running ICS). I seem to be able to open an >>>> unauthenticated baseband connection, but not an unauthenticated RFCOMM >>>> channel over an unauthenticated basebandconnection. >>>> >>>> What's odd is that I am able to open an unauthenticated baseband >>>> connection successfully, but when I try to open an RFCOMM channel over >>>> that connection, the devices try to pair. Here is roughly what I'm >>>> doing: >>>> >>>> /* >>>> * Before this part, I: >>>> * 1. Create device from a BT address string >>>> * 2. Perform an SDP query >>>> * 3. Extract the SDP record by UUID, make sure the service name >>>> matches my service >>>> * (whine that getServiceRecordForUUID returns one record instead of a list) >>>> * 4. Get the channel ID from SDP record >>>> */ >>>> >>>> // Try connecting to device >>>> if( [device openConnection:nil >>>> withPageTimeout:100000 >>>> authenticationRequired:false] != kIOReturnSuccess ) { >>>> NSLog(@"Couldn't open unauthenticated baseband connection to >>>> client device"); >>>> exit(3); >>>> } >>>> NSLog(@"\tOpened unauthenticated baseband connection successfully"); >>>> >>>> // Try opening an RFCOMM channel >>>> IOBluetoothRFCOMMChannel *channel = nil; >>>> IOReturn status; >>>> if ( [device openRFCOMMChannelSync:&channel >>>> withChannelID:channelID delegate:self] != kIOReturnSuccess) { >>>> NSLog(@"Couldn't open RFCOMM channel"); >>>> [device closeConnection]; >>>> exit(8); >>>> } >>>> NSLog(@"\tOpened RFCOMM channel"); >>>> >>>> The above code fails at the openRFCOMMChannelSync() call. >>>> >>>> I'm fairly certain that the other endpoint is doing what it's supposed >>>> to be doing -- I've been able to created unauthenticated RFCOMM >>>> channels to it using unbuntu without pairing the two devices. >>>> >>>> Can anyone point me in the right direction? Thanks! >>>> >>>> >>>> -Alexei >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/bluetooth-dev/mringwal%40inf.ethz.ch >>>> >>>> This email sent to mringwal(a)inf.ethz.ch >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/bluetooth-dev/ghazel%40gmail.com >>> >>> This email sent to ghazel(a)gmail.com >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/bluetooth-dev/mgillette%40apple.com > > This email sent to mgillette(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using unsecure/unauthenticated RFCOMM
by ghazel＠gmail.com 02 Mar '12

02 Mar '12

One thing I forgot to mention which is crucial for OS X since about 10.5.8. To avoid the pairing dialog when forming an outgoing connection, "Simple Pairing" must also be disabled. This can be done in Bluetooth Explorer or programmatically with BluetoothHCIWriteSimplePairingMode. Normally this switches out the number-confirmation style pairing for typed digits, but with authorization off and simple pairing off no dialog appears. -Greg On Mon, Feb 27, 2012 at 12:21 PM, Greg Hazel <ghazel(a)gmail.com> wrote: > Hi, > > I don't find it to be true that the Windows stack requires authentication. I have successfully connected pairs of authenticated devices on Windows using SO_BTH_AUTHENTICATE set to false and on bluez using RFCOMM_LM_AUTH set to false. Be sure that both the connecting socket and the listening socket have these set. Using those and openConnection on OS X with authenticationRequired:NO, I am able to form unauthenticated RFCOMM connections initiated by OS X. It seems that OS X has a limitation, or at least an oversight from the API I can find, which prevents it from listening for unauthenticated RFCOMM connections. > > I was actually hoping someone on this list knew a way to get OS X to not require authentication for incoming RFCOMM channels, since other platforms seem to support it. > > -Greg > > On Feb 27, 2012, at 5:11 AM, Matthias Ringwald wrote: > >> Hi >> >> I would assume that at least one of your devices insists on an authorized RFCOMM connection, which is at least true for Windows MS stack. >> >> It makes sense to allow unencrypted baseband connections - by this, you can do SDP queries and learn about the remote device before setting up an encrypted connection for the actual data. >> >> Best >> Matthias >> >> On Feb 23, 2012, at 7:09 PM, Alexei Czeskis wrote: >> >>> Hello! >>> >>> Does anyone have any experience using unsecure/unauthenticated RFCOMM >>> on OS X? I'm trying to do unsecure RFCOMM between two unpaired >>> bluetooth devices (one is a MacBook running 10.7.3, the other is an >>> Android phone running ICS). I seem to be able to open an >>> unauthenticated baseband connection, but not an unauthenticated RFCOMM >>> channel over an unauthenticated basebandconnection. >>> >>> What's odd is that I am able to open an unauthenticated baseband >>> connection successfully, but when I try to open an RFCOMM channel over >>> that connection, the devices try to pair. Here is roughly what I'm >>> doing: >>> >>> /* >>> * Before this part, I: >>> * 1. Create device from a BT address string >>> * 2. Perform an SDP query >>> * 3. Extract the SDP record by UUID, make sure the service name >>> matches my service >>> * (whine that getServiceRecordForUUID returns one record instead of a list) >>> * 4. Get the channel ID from SDP record >>> */ >>> >>> // Try connecting to device >>> if( [device openConnection:nil >>> withPageTimeout:100000 >>> authenticationRequired:false] != kIOReturnSuccess ) { >>> NSLog(@"Couldn't open unauthenticated baseband connection to >>> client device"); >>> exit(3); >>> } >>> NSLog(@"\tOpened unauthenticated baseband connection successfully"); >>> >>> // Try opening an RFCOMM channel >>> IOBluetoothRFCOMMChannel *channel = nil; >>> IOReturn status; >>> if ( [device openRFCOMMChannelSync:&channel >>> withChannelID:channelID delegate:self] != kIOReturnSuccess) { >>> NSLog(@"Couldn't open RFCOMM channel"); >>> [device closeConnection]; >>> exit(8); >>> } >>> NSLog(@"\tOpened RFCOMM channel"); >>> >>> The above code fails at the openRFCOMMChannelSync() call. >>> >>> I'm fairly certain that the other endpoint is doing what it's supposed >>> to be doing -- I've been able to created unauthenticated RFCOMM >>> channels to it using unbuntu without pairing the two devices. >>> >>> Can anyone point me in the right direction? Thanks! >>> >>> >>> -Alexei >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/bluetooth-dev/mringwal%40inf.ethz.ch >>> >>> This email sent to mringwal(a)inf.ethz.ch >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/bluetooth-dev/ghazel%40gmail.com >> >> This email sent to ghazel(a)gmail.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

"Random UUID's"
by Thomas Sorensen 02 Mar '12

02 Mar '12

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: GAP Discovery
by Tom Clark 01 Mar '12

01 Mar '12

Just a reminder, MFi related issues are not to be discussed on public mailing lists such as this. Please consult your MFi Licensee agreement for information about obtaining technical support. Thanks, -tom On Mar 1, 2012, at 1:55 AM, amay wrote: > > Hello， > Now we meet a problem in developing an app that utilitizes the bluetooth spp to connect to another bluetooth device. > we have sucessfully established the connection and pairing between iphone/ipod bluetooth and bluetooth device. > but when it gets to IDPS process using spp, we found that some IDPS command was not returned. > Such as SetFIDTokenvalues(0x39,FIDTokenValue is AccessoryCapsToken , EAProtocolToken or BundleSeedIDPreToken and so on). > For these reason, the IDPS process can not completed and the whole project have to be hold on now. > We are very desire to get some support about the problem. > Looking forwards to your reply. > Thank you! > > Thanks and best regards! > -------------------------------------------------------------------------------------------------------------- > 熊涛 > 锦锐科技有限公司 > C & A Technology Limited > Tel:0086 755 83949938 > Fax:0086 755 83949977 > http://www.cachip.com.cn > 地址:深圳市南山区科技园北区三号路博讯科技大楼二层 > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/bluetooth-dev/tc%40apple.com > > This email sent to tc(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

GAP Discovery
by amay 01 Mar '12

01 Mar '12

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0