Re: Using unsecure/unauthenticated RFCOMM
Re: Using unsecure/unauthenticated RFCOMM
- Subject: Re: Using unsecure/unauthenticated RFCOMM
- From: email@hidden
- Date: Thu, 01 Mar 2012 23:06:36 -0800
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 <email@hidden> 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 (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Bluetooth-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden