Im trying to open a L2Cap HID Channel And Interrupt channel so I can send HID commands to a bluetooth device.
I've done all my service advertising and device paring and established a baseband connection.
The Hid Control channel opens fine.
When I try to create my kBluetoothL2CAPPSMHIDInterrupt connection
l2capChannelQueueSpaceAvailable
delegate method called (not sure what this means) followed by
l2capChannelOpenComplete
but the connection closes immediately calling
l2capChannelClosed
How can I correctly open these connection?
I've spent a long time digging through the IOBlueTooth framework and the bluetooth.org HID spec but theres barely any helpful information (that I can find at least).
When i trace out my L2Cap channels I see some null values for
mIncomingDataListener
and
mEventDataListener
. I dont know how to set these or if they have anything to do with my problem.... just speculating.
The code snippet below is my attempt so far to make the connections after a connection to the device has been established.
-(void)establishL2CappConnections:(IOBluetoothDevice*)device
{
IOReturn r;
IOBluetoothL2CAPChannel *ch1;
r = [device openL2CAPChannelSync:&ch1
withPSM:(BluetoothL2CAPPSM)kBluetoothL2CAPPSMHIDControl
delegate:self];
self.mL2CappChannel=ch1;
NSLog(#"r == %i",r);
IOBluetoothL2CAPChannel *ch2;
r = [device openL2CAPChannelSync:&ch2
withPSM:(BluetoothL2CAPPSM)kBluetoothL2CAPPSMHIDInterrupt
delegate:self];
self.mL2CappInterruptChannel=ch2;
NSLog(#"r == %i",r);
}
Edit:1
I've attached my packet logs. It's strange, a request for
kBluetoothL2CAPPSMSDP 0x0001
gets made without me requesting it and then everything starts disconnecting.
BT Packet Logs
As per your logs its very clear that your device in in Limited Connection mode, its stays Active for 30sec or less. change device settings to make it General Discoverable.
kBluetoothL2CAPPSMSDP 0x0001
means Bit 13 - Limited Discoverable Mode
Playing with the Bluetooth settings will solve your problem
Related
I have problem with communication via USB CDC with Windows. On Linux or Mac everything work good.
So, when I try to connect to my COM port I get notification from PUTTY "Unable to open communication to COM2. Unable to configure port.
It is my own device based on Rx63n uC, I transmit in FullSpeed standard, packet in size less than 64 bytes. I'm used 2 endpoints for bulk transfer IN/OUT.
In USBLyzer I got information thatSTALL packet is received from my device after error (USBD_STATUS_CANCELED).
I used driver from Windows 10 usbser.sys.
Any ideas what is wrong?
I forgot to add that in USBLyzer I see a lot of my packets, and after transferred some data it generate error as above.
In Windows 7 I'm trying to set up a PPP connection over a direct serial port connection to a remote device. The documentation of the remote device (as well as the documentation I've found for the Windows PPP) indicates that the process should start with a Link Control Protocol packet, but I've discovered (by sniffing the serial line) that the PC, before doing anything else, is transmitting the string "CLIENT" once per second for up to 5 seconds. Only if the PC receives the response "SERVER" will it continue with the LCP initialization.
Does anyone know what level of system functionality is sending this CLIENT string, and how I can disable it. My remote device does not recognize this and refuses to connect based on this.
Update: I have discovered that this string is being initiated by the modem driver mdmhayes.inf as a "DialPrefix", but I have no idea how to update this driver file to eliminate this dial prefix. Thoughts?
Update: I've figured out how to get Windows to stop spitting out the "CLIENT" string (it has to do with changing the DIALPREFIX setting in the mdmhayes.inf file) but I still can't figure out how to make Windows realize it is connected and just move on with establishing the PPP connection. The modem diagnostics keep indicating that unknown strings are received so it doesn't know how to proceed. There should be some setting in the mdmhayes.inf file that tells the system not to wait for anything; it's connected to a wire and that's all that is needed. I just can't figure out what setting to use to make the modem initialization get out of the way to allow the PPP stack to take over.
in options.ttyS0 add:
debug
#19200
115200
192.168.111.1:192.168.111.2
netmask 255.255.255.0
lock
auth
nodefaultroute
nocrtscts
connect /etc/ppp/msclient.sh
msclient.sh :
#!/bin/sh
read -n 5 i
echo "SERVER"
I recently switched my Chromecast app to a custom receiver. I'm still using the Cast Companion Library. The custom receiver is basically based on this https://github.com/googlecast/cast-custom-receiver/blob/master/sample_media_receiver.html the only changes are the adding of a logo and loading screen and commenting out this line appConfig.maxInactivity = 6000; although at first I didn't have it commented out and still had the same issue.
Anyways the issue is pretty simple and only happens to a few people. It happens to me with one of my test devices, not all and not always. Basically I start streaming a video and it is all fine, then the device screen goes off, when I turn it off again the app has disconnected from the Chromecast. I do not have wifi set to turn off when sleeping, and all of the users who have complained about this claim their devices also don't have that setting turned on.
It could be a coincidence that this happened when I switched to the custom receiver but I just wanted to make sure there wasn't something I needed to add to my custom receiver to tell the CCL code to stay connected?
Thanks.
I faced similar issue today. Main cause for this behaviour is that as soon as the sender (in your case phone) is locked (sleep mode) then senderDisconnected event is fired on the receiver side. And if you check the event.reason, it will be unknow, so you could probably check for the reason, if it unknown then dont stop the playback on receiver (window.close).
When the sender itself disconnects, event.reason is "disconnected_from_sender".
I hope this helps.
It has nothing to do with maxInactivity.
The policy for disconnecting wifi when your phone goes to sleep does depend on the brand and vendor . Currently, the Cast SDK holds a lock to keep the wifi connected as long as there is a cast connection but even that is not a 100% guarantee to work for all phones/models/vendors/.... This has nothing to do with your receiver. The proper solution is not to try to fight against the wifi disconnect when phone goes to sleep, instead you have to consider adding some logic to recover the cast connectivity when phone wakes up and wifi connectivity is re-established (register a broadcast receiver to listen for wifi connectivity changes).
I have two iOS devices; one is sending beacons using peripheralManager, beaconPeripheralData, etc. The second, a receiver device, is currently scanning for regions and beacons of the same UUID using didEnterRegion, didRangeBeacons, etc.
Is there any method or callback for the -broadcaster- side to know if the scanning side has entered its region or received its beacon? Something similar to "didEnterRegion", but for the broadcaster.
Thanks.
Simple answer - no.
Not so simple answer - clients don't connect to the "broadcaster", they just listen for advertisements, so there is no way for "broadcasters" to identify who has "heard" them.
Vladimir's answer is correct. However, you can set up your "broadcaster" (advertiser, in BLE terms) to also listen for other BLE devices that are advertising services, or sending out iBeacon broadcasts.
Then you would set up the remote receiving iOS app to execute special code when it gets a didEnterRegion call. That code could start advertising a pre-defined BLE service that your "broadcaster" is already listening for, and the two devices could then enter into a 2-way BLE conversation.
More simply, your receiver could simply start sending it's own beacon signal when it gets a didEnterRegion message as a result of detecting the "broadcaster"'s beacon signal.
You can do this is you just use CoreBluetooth CBCentral and CBPeripheral rather than trying to be an iBeacon (which encourages non-connectability).
While there is no standard way for a broadcaster or peripheral to automatically know who's found it you can do this by having an service and characteristic on your iOS peripheral. You could have your central scan for a particular UUID and when it finds it, have it connect and write an attribute, and then disconnect. This would give your peripheral information about who saw it.
This avoids the issue where you try to toggle between one device being a broadcaster and a central, since you can't be both of them at the same time.
I am trying to use IOBluetooth framework on OS X 10.8.2 to connect with the bluetooth enabled phones emulating computer as a hands free device. I can successfully make a connection with the phone and phone can recognise the connection as a HandsFree connected to the phone.
But when I try to make a call with the phone and want to send the audio to the mac (by selecting the source as handsfree), the audio never reaches the computer.
As at this point the bluetooth framework tries to open a SCO Audio connection with the device, but the connection establishment is never successful and I get the error code 0x0D status code in scoConnectionOpened status.
I am using IOBluetoothAddSCOAudioDevice function to attach the SCO Audio device with bluetooth device and it is always successful.
//btDevice is paired
res=IOBluetoothAddSCOAudioDevice((IOBluetoothDeviceRef) btDevice,NULL);
if(res != kIOReturnSuccess)
{
self.error.title = [NSString stringWithFormat:
#"Could not attach the Audio device. Try paring device again"];
}
The console log says
24/11/2012 4:02:13.000 PM kernel[0]: [SendHCIRequestFormatted] ###
ERROR: [0x0428] (Setup Synchronous Connection) -- Send request failed
(err = 0x000D (kBluetoothHCIErrorHostRejectedLimitedResources))
24/11/2012 4:02:13.000 PM kernel[0]: REQUIRE_NO_ERR failure: 0xd -
file:
/SourceCache/IOBluetoothFamily_kexts/IOBluetoothFamily-4090.4.33/Core/Family/Drivers/IOBluetoothSCOAudioDriver/IOBluetoothSCOAudioDevice.cpp:872
Although console log says limited resources but I have tried it with multiple phones having their batteries full.
I am stumped on this and just thinking if I need to do any thing special or different?
Thanks in advance for much appreciated help.
This error ("Connection Rejected due to Limited resource") typically happens when a T2 request is sent to a T1-only SCO listener. If you read the patch notes to version 5 you can get a discussion about this problem linux-bluetooth v5 patch notes