site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com Hi all, Thanks in advance for any advice, b ******************** Brian M. Criscuolo Lead Software Engineer Mark/Space, Inc. bcriscuolo@markspace.com <http://www.markspace.com> Changes: -MyServerSample simply changes the UUID in the SDP dictionary plist. status is generally 0x2c5 here. 7. Click "Connect" on the Leopard machine again -- Unsuccessful connection, with the same error as in step 6. 8. Click "Start Server" on the Tiger machine. 9. Click "Connect" on the Leopard machine. -- Unsuccessful connection, with the same error as in step 6. _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.a... I'm a long-time developer, short-time Bluetooth developer, although long enough to make me dangerous. :) I'm working on a project in which the Mac will make connections to a phone that is running a RFComm service with our custom UUID in the SDP description. Generally, this works. Below describes a situation where it doesn't work, reproduced *without* having to add the phone to the mix, by using Apple's sample RFComm client and server apps. Below is part of a Radar I've filed (rdar://5692399) and I'm working with DTS on this. I'm putting it out here in hopes that someone else might have an idea, as this regression is a serious issue to the feature we're working on. I can email directly the projects if anyone would like them. Summary: Connections to a Bluetooth RFComm server from a BT client fail repeatedly even though the server is publishing (correctly) its SDP entry and accepting incoming connections. This is if the client is on Leopard; the behavior does not happen if the client is running on Tiger. Steps to Reproduce: I'm using a *slight* modification to the RFCommClientSample and RFCommServerSample projects that are included with XCode. My code is based on these applications, but illustrating the issue with your samples is far easier. I've attached both of these projects. -MyClientSample simply changes connectToServer in ChatBluetoothInterface_ObjC.m so that rather than showing the device selector each time you hit the connect button, it remembers the device for the next time you hit the connect button. Also, I changed the UUID to that of my service running on the server. 1. Launch MyServerSample on a Tiger machine (10.4.11 used in my tests). 2. Launch MyClientSample on a Leopard machine (10.5.1 and 10.5.2 9C16 used in my tests). 3. Click "Start Server" on the Tiger machine. 4. Click "Connect" on the Leopard machine. --Successful connection 5. Click "Disconnect" on the Leopard machine. 6. Click "Connect" on the Leopard machine. -- Unsuccessful connection, because the server stops when the disconnect in step 5 occurs. This is fine, and expected, and proper. The error comes in ChatBluetoothInterface_ObjC.m: status = [selectedDevice openRFCOMMChannelSync:&mRFCOMMChannel withChannelID:rfcommChannelID delegate:self]; Expected Results: The expectation is that in step 8, the connection would be made properly - as it was in step 4. An error in connecting previously should not be causing a later connection attempt to fail, especially when all steps and logic is the same. Actual Results: The connection fails repeatedly. The only way to rectify this situation is to terminate the client application and relaunch it. Regression: This problem occurs when the client is running on Leopard. It *does not* happen when the configuration is reversed - server on Leopard, client on Tiger. This email sent to site_archiver@lists.apple.com